Active vs Inactive Relationship di Power BI: Panduan Lengkap USERELATIONSHIP dan Role-Playing Dimension

Dalam artikel sebelumnya kita telah membahas cardinality seperti One-to-One, One-to-Many, dan Many-to-Many, kemudian mempelajari bagaimana Cross Filter Direction menentukan arah filter melalui relationship.

Sekarang kita sampai pada konsep relationship berikutnya yang sangat penting:

Active Relationship

dan:

Inactive Relationship.

Jika Anda pernah membuka Model View Power BI, mungkin Anda melihat sebagian relationship digambarkan menggunakan garis solid, sementara relationship lainnya menggunakan garis putus-putus.

Garis tersebut bukan sekadar perbedaan desain.

Garis solid menunjukkan relationship yang active.

Garis putus-putus menunjukkan relationship yang inactive.

Perbedaan tersebut menentukan relationship mana yang secara default digunakan Power BI untuk melakukan filter propagation.

Masalah ini paling sering muncul ketika sebuah fact table mempunyai beberapa kolom yang secara logis berhubungan dengan dimension yang sama.

Contoh paling klasik:

FactSales mempunyai:

OrderDate

ShipDate

DeliveryDate.

Ketiga kolom tersebut sebenarnya sama-sama merupakan tanggal.

Semua ingin dihubungkan dengan:

DimDate[Date]

Tetapi Power BI tidak dapat menggunakan ketiganya sebagai jalur filter default secara bersamaan.

Microsoft menjelaskan bahwa hanya terdapat satu active filter propagation path antara dua model tables. Relationship tambahan dapat dibuat, tetapi harus inactive dan baru digunakan ketika sebuah calculation secara eksplisit memintanya melalui fungsi DAX USERELATIONSHIP.

Di sinilah USERELATIONSHIP menjadi sangat penting.

Apa Itu Active Relationship?

Active Relationship adalah relationship yang secara default digunakan Power BI untuk melakukan filter propagation di antara dua tabel.

Misalnya terdapat:

DimDate[Date]

dan:

FactSales[OrderDate].

Relationship:

DimDate[Date] 1 → * FactSales[OrderDate]

Jika relationship tersebut active, maka ketika user memilih:

Year = 2026

atau:

Month = September,

filter dari DimDate secara otomatis bergerak melalui relationship tersebut menuju FactSales[OrderDate].

Artinya seluruh measure standar FactSales akan dianalisis berdasarkan Order Date.

Contoh:

Total Sales =
SUM(FactSales[SalesAmount])

Measure tersebut tidak menyebut OrderDate sama sekali.

Namun ketika visual menggunakan DimDate, Power BI menggunakan active relationship sebagai jalur filter default.

Bagaimana Active Relationship Ditampilkan?

Dalam Model View, active relationship ditampilkan menggunakan garis solid.

Secara konseptual:

DimDate ━━━━━ FactSales

Garis solid berarti:

Relationship ini tersedia untuk filter propagation secara default.

Microsoft juga menggunakan representasi continuous/solid line ini dalam tutorial dimensional modeling Power BI.

Apa Itu Inactive Relationship?

Inactive Relationship adalah relationship yang terdapat dalam semantic model tetapi tidak digunakan sebagai jalur filter default.

Misalnya:

DimDate[Date] → FactSales[ShipDate]

relationship tersebut dapat dibuat tetapi ditetapkan inactive.

Dalam Model View biasanya terlihat sebagai:

DimDate – – – – – FactSales

atau garis putus-putus.

Relationship tersebut tetap ada.

Power BI mengetahui hubungan antara kedua kolom.

Namun relationship itu tidak digunakan secara otomatis ketika filter diterapkan.

Inactive Tidak Berarti Relationship Salah

Ini merupakan kesalahpahaman yang cukup umum.

Inactive relationship bukan relationship rusak.

Bukan pula relationship yang tidak digunakan sama sekali.

Ia merupakan relationship valid yang sengaja tidak dipilih sebagai jalur default.

Kita dapat mengaktifkannya sementara ketika sebuah calculation membutuhkan relationship tersebut.

Caranya:

USERELATIONSHIP.

Mengapa Power BI Membutuhkan Active dan Inactive Relationship?

Bayangkan FactSales:

OrderID	OrderDate	ShipDate	SalesAmount
1001	2026-09-01	2026-09-03	500000
1002	2026-09-02	2026-09-05	750000
1003	2026-09-05	2026-09-10	400000

Kemudian terdapat DimDate:

Date	Year	Month
2026-09-01	2026	September
2026-09-02	2026	September
…	…	…

Kita ingin DimDate digunakan untuk dua pertanyaan berbeda:

Berapa Sales berdasarkan Order Date?

Berapa Sales berdasarkan Ship Date?

Secara logis terdapat dua relationship:

DimDate[Date] → FactSales[OrderDate]

DimDate[Date] → FactSales[ShipDate].

Jika kedua relationship menjadi default secara bersamaan, Power BI tidak mempunyai satu definisi yang jelas ketika user memilih September:

Apakah September harus memfilter OrderDate atau ShipDate?

Untuk menghindari ambiguity tersebut, salah satunya active dan lainnya inactive.

Hanya Satu Active Relationship antara Dua Tabel

Power BI hanya mengizinkan satu relationship active antara dua tabel pada satu waktu ketika relationship tersebut merupakan alternative filter paths antara pasangan tabel yang sama.

Microsoft menjelaskan bahwa active relationship menjadi default relationship. Jika terdapat beberapa relationship antara dua tabel, hanya salah satunya yang dapat menjadi relationship default.

Contoh:

ACTIVE

DimDate[Date] → FactSales[OrderDate]

INACTIVE

DimDate[Date] → FactSales[ShipDate]

INACTIVE

DimDate[Date] → FactSales[DeliveryDate]

Bagaimana Menentukan Mana yang Harus Active?

Relationship active idealnya merepresentasikan role yang paling sering digunakan sebagai default reporting context.

Dalam sales model biasanya:

Order Date

sering menjadi tanggal utama.

Karena itu:

DimDate → OrderDate

dibuat active.

ShipDate dan DeliveryDate tetap tersedia tetapi inactive.

Microsoft menggunakan contoh yang sama: OrderDate menjadi active relationship karena sebagian besar measure perlu dianalisis berdasarkan tanggal order, sedangkan ShipDate hanya digunakan oleh measure tertentu.

Contoh Measure Menggunakan Active Relationship

Misalnya:

Orders =
COUNTROWS(FactSales)

Relationship active:

DimDate → FactSales[OrderDate].

Jika report menampilkan:

January

February

March,

maka Orders secara otomatis dihitung berdasarkan:

OrderDate.

Tidak diperlukan DAX khusus.

Bagaimana Menggunakan Ship Date?

Karena relationship ShipDate inactive, measure biasa tidak akan menggunakannya.

Kita membutuhkan:

USERELATIONSHIP.

Contoh:

Orders Shipped =
CALCULATE(
    COUNTROWS(FactSales),
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Microsoft menggunakan pola yang sama dalam dokumentasi active vs inactive relationship.

Apa Itu USERELATIONSHIP?

USERELATIONSHIP merupakan fungsi DAX yang menentukan relationship model mana yang harus digunakan selama calculation tertentu dievaluasi.

Syntax dasarnya:

USERELATIONSHIP(
    <columnName1>,
    <columnName2>
)

Microsoft menjelaskan bahwa USERELATIONSHIP tidak mengembalikan sebuah nilai. Fungsi ini hanya mengaktifkan relationship yang ditentukan selama calculation berlangsung.

USERELATIONSHIP Biasanya Digunakan di Dalam CALCULATE

Contoh paling umum:

Sales by Ship Date =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Jika:

Total Sales =
SUM(FactSales[SalesAmount])

maka measure pertama menggunakan OrderDate active relationship.

Measure kedua menggunakan ShipDate relationship.

USERELATIONSHIP Tidak Membuat Relationship Baru

Ini sangat penting.

USERELATIONSHIP hanya dapat menggunakan relationship yang sudah terdapat di semantic model.

Anda tidak dapat menuliskan dua kolom yang tidak mempunyai relationship dan berharap USERELATIONSHIP menciptakan relationship virtual.

Microsoft menjelaskan bahwa fungsi ini mengidentifikasi existing relationship berdasarkan dua endpoint column yang diberikan. Jika kedua kolom tersebut bukan bagian relationship yang sama, expression menghasilkan error.

Apakah Relationship Harus Inactive?

Menariknya, secara teknis USERELATIONSHIP dapat menunjuk relationship yang active maupun inactive.

Status relationship tidak menentukan apakah fungsi tersebut dapat memakainya.

Namun use case paling umum USERELATIONSHIP memang untuk:

menggunakan inactive relationship.

Microsoft menjelaskan bahwa relationship yang disebut dalam USERELATIONSHIP digunakan selama calculation dan dapat mengoverride relationship active lain yang tidak disebutkan.

Apa yang Terjadi pada Active Relationship Saat USERELATIONSHIP Digunakan?

Misalnya terdapat:

Active:

DimDate → OrderDate.

Inactive:

DimDate → ShipDate.

Measure:

Shipped Sales =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Untuk calculation tersebut, filter Date diarahkan melalui relationship ShipDate.

Active relationship OrderDate tidak menjadi jalur filter yang digunakan untuk role tanggal tersebut selama calculation itu berlangsung.

Dokumentasi CALCULATE Microsoft juga mendeskripsikan USERELATIONSHIP sebagai filter modifier yang menggunakan inactive relationship dan membuat active relationship terkait tidak digunakan selama evaluation tersebut.

Contoh Lengkap Order Date vs Ship Date

Misalnya kita memiliki data:

OrderID	OrderDate	ShipDate	Sales
1001	1 Jan	3 Jan	100
1002	1 Jan	5 Jan	200
1003	3 Jan	5 Jan	300

Active relationship:

Date → OrderDate.

Measure:

Total Sales =
SUM(FactSales[Sales])

Pada 1 Jan:

Total Sales = 300.

Karena Order 1001 dan 1002 dibuat pada 1 Jan.

Sekarang:

Shipped Sales =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Pada 5 Jan:

Shipped Sales = 500.

Karena Order 1002 dan 1003 dikirim pada 5 Jan.

Satu Date table.

Satu Fact table.

Dua interpretation tanggal berbeda.

Apa Itu Role-Playing Dimension?

Kasus Date tadi disebut:

role-playing dimension.

Satu logical dimension memainkan beberapa role terhadap fact table.

Misalnya Date berperan sebagai:

Order Date;

Ship Date;

Delivery Date.

Dimension dasarnya sama:

Date.

Tetapi business role-nya berbeda.

Contoh Role-Playing Dimension Lain

Konsep ini tidak terbatas pada Date.

Misalnya Airport dimension:

Departure Airport;

Arrival Airport.

Employee dimension:

Salesperson;

Manager.

Geography:

Origin;

Destination.

Warehouse:

Source Warehouse;

Destination Warehouse.

Business entity sama, tetapi memainkan role yang berbeda.

Dua Cara Memodelkan Role-Playing Dimension

Pada dasarnya terdapat dua pendekatan utama.

Pendekatan pertama:

satu dimension + active/inactive relationships + USERELATIONSHIP.

Pendekatan kedua:

menduplikasi role-playing dimension sehingga setiap role mempunyai active relationship sendiri.

Approach 1: Satu Date Table + USERELATIONSHIP

Model:

DimDate → OrderDate ACTIVE

DimDate – – → ShipDate INACTIVE.

Keuntungannya:

jumlah tabel lebih sedikit;

model terlihat ringkas;

satu Date dimension dapat digunakan beberapa role.

Kekurangannya:

report author harus menggunakan measure khusus untuk inactive relationship;

Ship Date tidak dapat digunakan dengan field biasa secara natural seperti active relationship;

dan penggunaan simultan beberapa role lebih terbatas.

Approach 2: Duplicate Date Dimension

Model:

Order Date

1 → * FactSales[OrderDate]

Ship Date

1 → * FactSales[ShipDate]

Semua relationship active.

Sekarang report dapat mempunyai:

Order Year

dan:

Ship Year

dalam visual yang sama.

Filter kedua role juga dapat bekerja secara independent.

Mana yang Direkomendasikan Microsoft?

Microsoft merekomendasikan untuk mendefinisikan active relationships whenever possible, terutama ketika model menggunakan Row-Level Security.

Konsekuensinya, untuk role-playing dimension Microsoft menyarankan mempertimbangkan duplikasi dimension sehingga masing-masing role dapat mempunyai active relationship sendiri.

Inactive relationship tetap valid ketika:

tidak ada requirement untuk memfilter secara simultan berdasarkan role berbeda;

dan USERELATIONSHIP digunakan pada calculation tertentu yang relevan.

Mengapa Active Relationship Lebih Fleksibel?

Active relationships dapat digunakan secara natural oleh:

report visuals;

slicers;

measures;

Q&A;

dan fitur semantic model lainnya.

Inactive relationship membutuhkan explicit DAX measure agar digunakan.

Report author tidak dapat hanya menarik field Date dan berharap Power BI mengetahui bahwa visual tertentu harus menggunakan ShipDate.

Contoh Keterbatasan Satu Date Table

Bayangkan pengguna ingin membuat matrix:

Rows:

Order Month

Columns:

Ship Month.

Dengan satu Date table yang hanya mempunyai satu active relationship, requirement tersebut sulit diwujudkan secara natural.

Dengan:

DimOrderDate

dan:

DimShipDate,

kedua role menjadi jelas.

Role-Playing Dimension dan Usability

Model bukan hanya harus benar secara teknis.

Model juga harus mudah digunakan.

Bayangkan report author melihat satu tabel:

Date.

Mereka kemudian harus mengetahui:

Total Sales = Order Date.

Shipped Sales = Ship Date.

Delivered Sales = Delivery Date.

Ini dapat bekerja.

Namun semakin banyak measure, semakin tinggi cognitive load.

Dengan dimension:

Order Date

Ship Date

Delivery Date,

business semantics menjadi lebih eksplisit.

Kelemahan Duplicate Dimension

Tentu ada trade-off.

Jika Date dimension mempunyai banyak column:

Date;

Year;

Quarter;

Month;

Week;

Fiscal Year;

Fiscal Period,

menduplikasi role-playing Date membuat jumlah tabel dan field lebih banyak.

Model secara visual menjadi lebih besar.

Namun Microsoft menilai trade-off tersebut sering layak ketika active relationship memberikan usability dan RLS behavior yang lebih baik.

Inactive Relationship dan Row-Level Security

Ini bagian yang sangat penting.

Microsoft menyatakan bahwa RLS filters hanya dipropagasikan melalui active relationships.

RLS tidak dipropagasikan melalui inactive relationships meskipun measure menggunakan USERELATIONSHIP.

Dengan kata lain:

USERELATIONSHIP bukan cara untuk “mengaktifkan RLS” melalui inactive relationship.

Mengapa Ini Penting?

Bayangkan security table memfilter Date.

Anda berharap ShipDate relationship inactive digunakan dengan USERELATIONSHIP dan security ikut bergerak.

Jangan membuat asumsi tersebut.

RLS mempunyai aturan relationship propagation sendiri.

Jika keamanan data bergantung pada sebuah role, desain active relationship perlu dipertimbangkan sejak awal.

USERELATIONSHIP dan RLS Memiliki Restriction Tambahan

Dokumentasi DAX USERELATIONSHIP juga menjelaskan adanya restriction ketika Row-Level Security didefinisikan pada tabel yang terkait dengan calculation tertentu. Dalam kondisi tersebut, USERELATIONSHIP dapat menghasilkan error.

Karena itu untuk model enterprise dengan RLS:

jangan memilih architecture active/inactive hanya berdasarkan convenience DAX.

Evaluasi security behavior terlebih dahulu.

USERELATIONSHIP Adalah Filter Modifier

USERELATIONSHIP sering dianggap seperti fungsi yang menghasilkan data.

Sebenarnya tidak.

Ia merupakan modifier terhadap bagaimana filter context bergerak selama calculation.

Karena itu USERELATIONSHIP biasanya berada di:

CALCULATE

atau:

CALCULATETABLE

dan fungsi lain yang menerima filter modifier.

Microsoft mendokumentasikan USERELATIONSHIP sebagai fungsi yang digunakan oleh calculation functions seperti CALCULATE dan CALCULATETABLE.

USERELATIONSHIP dan CALCULATE

Contoh:

Orders Shipped =
CALCULATE(
    [Orders],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Secara konseptual:

CALCULATE berkata:

Hitung [Orders] dalam filter context yang dimodifikasi.

USERELATIONSHIP berkata:

Untuk calculation ini, gunakan Date ↔ ShipDate relationship.

Contoh Beberapa Measure Tanggal

Total Sales =
SUM(FactSales[SalesAmount])

Default:

Order Date.

Sales by Ship Date =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Sales by Delivery Date =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[DeliveryDate]
    )
)

Satu base measure dapat digunakan kembali.

Hanya filter path yang diubah.

Measure Branching dengan USERELATIONSHIP

Ini merupakan pattern yang baik.

Buat base measure:

Total Sales =
SUM(FactSales[SalesAmount])

Kemudian reuse:

Shipped Sales =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Daripada menulis:

Shipped Sales =
CALCULATE(
    SUM(FactSales[SalesAmount]),
    USERELATIONSHIP(...)
)

di seluruh measure.

Measure branching membuat model lebih mudah dipelihara.

USERELATIONSHIP Tidak Mengubah Model Secara Permanen

Jika ShipDate relationship inactive di Model View, menjalankan measure USERELATIONSHIP tidak membuat garisnya berubah menjadi solid.

Relationship tetap inactive.

Activation hanya terjadi selama evaluation measure.

Setelah calculation selesai:

model kembali ke default relationship behavior.

USERELATIONSHIP dan Multiple Relationships

Jika calculation membutuhkan beberapa inactive relationships sekaligus, masing-masing relationship perlu disebutkan melalui USERELATIONSHIP tersendiri.

Microsoft mendokumentasikan bahwa setiap relationship yang diperlukan harus diberikan melalui call USERELATIONSHIP terpisah.

Contoh konseptual:

Special Measure =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(...),
    USERELATIONSHIP(...)
)

Nested USERELATIONSHIP

USERELATIONSHIP juga dapat muncul dalam nested CALCULATE.

Jika beberapa USERELATIONSHIP saling conflict, Microsoft menjelaskan bahwa relationship pada nested expression yang lebih dalam dapat memperoleh prioritas lebih tinggi.

Ini merupakan skenario advanced.

Untuk sebagian besar model bisnis, hindari kompleksitas semacam itu kecuali memang diperlukan.

Relationship Weight dan USERELATIONSHIP

Dalam internal relationship resolution, Power BI menggunakan konsep path priority dan relationship weight.

Microsoft menjelaskan bahwa USERELATIONSHIP dapat memengaruhi weight relationship sehingga Power BI dapat memilih path tertentu ketika terdapat beberapa jalur.

Ini menjelaskan mengapa USERELATIONSHIP tidak sekadar “switch inactive to active”.

Secara teknis fungsi tersebut juga membantu engine menentukan relationship path yang harus diberi prioritas untuk calculation tersebut.

Active Relationship dan Ambiguity

Mengapa Power BI membatasi active paths?

Karena filter harus mempunyai jalur yang jelas.

Bayangkan jika Date dapat memfilter Sales melalui:

OrderDate

dan ShipDate

secara bersamaan.

Jika user memilih 1 Januari, apa artinya?

Order dibuat pada 1 Januari?

Order dikirim pada 1 Januari?

Atau harus memenuhi keduanya?

Active relationship menentukan default interpretation.

Inactive Relationship Adalah Cara Mengelola Alternative Paths

Inactive relationship memungkinkan model menyimpan pengetahuan tentang relationship alternatif tanpa menjadikannya default.

Dalam model:

OrderDate = default.

ShipDate = alternative.

DeliveryDate = alternative.

Calculation kemudian memilih alternative path bila diperlukan.

Apa yang Terjadi Jika Power BI Auto Detect Memilih Relationship yang Salah?

Power BI dapat secara otomatis membuat relationship.

Jika terdapat beberapa kemungkinan relationship antara dua tabel, salah satunya dapat ditetapkan active.

Tetapi pilihan otomatis tersebut belum tentu sesuai business semantics.

Microsoft secara khusus menyebut kasus wrong active relationship dan merekomendasikan menggunakan Manage Relationships atau Edit Relationship untuk menentukan relationship mana yang seharusnya active.

Jangan Mengandalkan Nama Kolom Saja

Misalnya terdapat:

CreatedDate

ModifiedDate

ClosedDate.

Power BI tidak mengetahui mana yang merupakan tanggal bisnis utama untuk reporting.

Developer harus memahami requirement.

Jika dashboard utama berbicara tentang kasus berdasarkan Created Date:

CreatedDate seharusnya menjadi default.

Jika laporan utama berbasis Closed Date:

mungkin ClosedDate yang lebih tepat menjadi active.

Inactive Relationship dan Table Expansion

Ada nuance Power BI yang menarik.

Inactive relationship tidak digunakan untuk filter propagation secara default.

Namun Microsoft menjelaskan bahwa table expansion tetap mempertimbangkan inactive relationships. Akibatnya BLANK dapat muncul pada slicer atau visual karena missing values di sisi relationship inactive.

Ini sering mengejutkan developer.

Contoh BLANK pada ShipDate

Misalnya beberapa order belum dikirim.

ShipDate = BLANK.

Relationship ShipDate inactive.

Anda mungkin berpikir:

Karena inactive, ShipDate tidak akan memengaruhi Date table sama sekali.

Namun table expansion dapat menyebabkan BLANK member terlihat pada Date slicer.

Microsoft mendokumentasikan behavior tersebut pada contoh OrderDate/ShipDate.

Inactive Tidak Sama dengan Disabled

Ini distinction penting.

Inactive berarti:

relationship tidak melakukan default filter propagation.

Bukan:

relationship sepenuhnya diabaikan engine dalam segala situasi.

Beberapa behavior model seperti table expansion masih dapat melibatkan relationship tersebut.

USERELATIONSHIP vs CROSSFILTER

Kedua fungsi ini sering tertukar.

USERELATIONSHIP memilih relationship yang digunakan.

CROSSFILTER mengubah arah filtering relationship.

Contoh:

USERELATIONSHIP menjawab:

Gunakan OrderDate atau ShipDate?

CROSSFILTER menjawab:

Filter boleh berjalan satu arah, dua arah, atau tidak sama sekali?

USERELATIONSHIP vs TREATAS

USERELATIONSHIP membutuhkan existing physical relationship.

TREATAS dapat menerapkan nilai dari satu table expression sebagai filter terhadap column lain tanpa relationship fisik yang sama.

Karena itu TREATAS sering disebut:

virtual relationship pattern.

Namun jika relationship benar-benar merupakan bagian fundamental model:

physical relationship biasanya lebih mudah dipahami dan dikelola.

USERELATIONSHIP vs Duplicate Dimension

Aspek	USERELATIONSHIP	Duplicate Dimension
Jumlah dimension	Lebih sedikit	Lebih banyak
Relationship	Active + inactive	Semua bisa active
Measure khusus	Diperlukan untuk inactive role	Tidak selalu
Simultaneous filtering by role	Lebih terbatas	Lebih natural
RLS	Perlu perhatian besar	Lebih konsisten melalui active paths
Data pane	Lebih sedikit tabel	Lebih banyak field/tabel
Usability	Membutuhkan knowledge measure	Role lebih eksplisit

Kapan Sebaiknya Menggunakan Inactive Relationship?

Inactive relationship sangat cocok ketika:

satu dimension mempunyai beberapa role terhadap fact;

satu role jelas merupakan default;

role alternatif hanya diperlukan oleh sejumlah calculation tertentu;

tidak ada kebutuhan untuk memfilter visual secara simultan berdasarkan beberapa role;

dan RLS tidak bergantung pada inactive path.

Ini konsisten dengan guidance Microsoft.

Kapan Lebih Baik Duplicate Dimension?

Pertimbangkan duplicate dimension ketika:

Order Date dan Ship Date sering digunakan secara bersamaan;

report author perlu bebas membuat visual tanpa measure khusus;

RLS perlu berjalan melalui semua role;

Q&A atau self-service reporting penting;

atau business semantics akan menjadi lebih jelas dengan role-specific dimensions.

Contoh FMCG: Order Date vs Delivery Date

Bayangkan distributor FMCG mempunyai:

FactSalesOrder:

OrderDate

DeliveryDate

InvoiceDate.

Dashboard sales harian biasanya dianalisis berdasarkan:

Order Date.

Maka:

DimDate → OrderDate

active.

Kemudian supply chain ingin menghitung nilai order yang benar-benar dikirim pada suatu hari.

Kita dapat menggunakan:

Delivered Sales =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSalesOrder[DeliveryDate]
    )
)

Contoh HR: Hire Date vs Termination Date

Employee fact/history mempunyai:

HireDate

TerminationDate.

Jika headcount analysis default menggunakan Hire Date, relationship tersebut active.

Untuk melihat termination:

Employees Terminated =
CALCULATE(
    COUNTROWS(FactEmployee),
    USERELATIONSHIP(
        DimDate[Date],
        FactEmployee[TerminationDate]
    )
)

Namun jika user sering membandingkan:

Hires by Month

versus:

Terminations by Month,

role-specific Date dimensions mungkin lebih intuitif.

Contoh Logistics: Origin vs Destination

Shipment mempunyai:

OriginLocationKey

DestinationLocationKey.

Satu DimLocation dapat secara teknis mempunyai:

active relationship ke Origin

inactive relationship ke Destination.

Measure tertentu menggunakan USERELATIONSHIP untuk Destination.

Namun jika report perlu menampilkan:

Origin City

dan Destination City

secara bersamaan dalam visual, duplicate role-playing dimension:

DimOrigin

DimDestination

sering jauh lebih natural.

Contoh Airport

FactFlight mempunyai:

DepartureAirportKey

ArrivalAirportKey.

Jika hanya satu DimAirport digunakan:

salah satu relationship active;

satu inactive.

Tetapi hampir setiap flight report ingin melihat:

Departure Airport

dan:

Arrival Airport

bersamaan.

Dalam kasus ini duplicate dimensions lebih masuk akal.

Kesalahan Umum 1: Mengira Dashed Relationship Tidak Berfungsi

Inactive relationship tetap valid.

Ia hanya tidak menjadi default filter path.

Gunakan USERELATIONSHIP untuk calculation yang membutuhkan relationship tersebut.

Kesalahan Umum 2: Membuat Semua Relationship Active

Power BI tidak akan mengizinkan semua alternative paths menjadi active jika menyebabkan ambiguous default filtering.

Jangan mencoba “memperbaiki” dashed relationship hanya karena terlihat berbeda.

Inactive dapat merupakan desain yang memang disengaja.

Kesalahan Umum 3: USERELATIONSHIP Tanpa CALCULATE

USERELATIONSHIP bukan standalone calculation.

Contoh salah secara konseptual:

My Measure =
USERELATIONSHIP(
    DimDate[Date],
    FactSales[ShipDate]
)

USERELATIONSHIP tidak mengembalikan scalar result.

Gunakan di dalam function seperti CALCULATE.

Kesalahan Umum 4: Menggunakan Kolom yang Tidak Mempunyai Relationship

Contoh:

USERELATIONSHIP(
    TableA[SomeColumn],
    TableB[AnotherColumn]
)

tidak akan menciptakan relationship baru.

Existing model relationship harus sudah tersedia.

Kesalahan Umum 5: Menganggap USERELATIONSHIP Mengubah Model Permanen

Tidak.

Measure tidak mengubah relationship configuration Model View.

Ia hanya mengubah relationship yang digunakan selama evaluation calculation.

Kesalahan Umum 6: Mengandalkan Inactive Relationship untuk RLS

Ini berbahaya.

Microsoft menegaskan bahwa RLS hanya dipropagasikan melalui active relationships.

Jika security architecture bergantung pada inactive relationship, redesign model sebelum deployment.

Kesalahan Umum 7: Terlalu Banyak Measure USERELATIONSHIP

Misalnya terdapat 80 base measures.

Kemudian semua harus mempunyai:

Order Date version

Ship Date version

Delivery Date version.

Model dapat berubah menjadi ratusan measures.

Microsoft menyebut bahwa pattern single role-playing dimension dapat menghasilkan Data pane yang penuh measure ketika banyak calculations memerlukan alternative date relationships.

Ini sinyal bahwa role-playing dimensions terpisah mungkin lebih baik.

Kesalahan Umum 8: Default Relationship Tidak Sesuai Business Meaning

Jika 90% dashboard berbicara tentang Ship Date tetapi OrderDate yang active, developer harus menggunakan USERELATIONSHIP hampir di mana-mana.

Ini kemungkinan berarti default relationship Anda salah.

Active relationship sebaiknya merepresentasikan role yang benar-benar menjadi default analysis.

Troubleshooting: Measure Menggunakan Tanggal yang Salah

Misalnya:

Total Sales by Month

memberikan angka berdasarkan OrderDate padahal Anda ingin ShipDate.

Periksa:

relationship Date mana yang active.

Jika ShipDate inactive, gunakan USERELATIONSHIP atau redesign Date role.

Troubleshooting: USERELATIONSHIP Tidak Mengubah Hasil

Periksa:

apakah kolom yang digunakan benar;

apakah relationship memang sudah ada;

apakah Date context benar-benar berasal dari DimDate;

apakah ShipDate memiliki nilai;

dan apakah filter lain menyebabkan hasil tetap sama.

Troubleshooting: BLANK Muncul di Date Slicer

Periksa inactive relationship ke date column lain.

Misalnya ShipDate memiliki BLANK untuk order yang belum dikirim.

Table expansion dapat mempertimbangkan inactive relationship dan menyebabkan BLANK member terlihat.

Troubleshooting: Tidak Bisa Menjadikan Relationship Active

Kemungkinan sudah terdapat active filter path lain antara kedua tabel.

Untuk mengaktifkan relationship yang baru:

relationship active lama harus diubah menjadi inactive terlebih dahulu.

Microsoft menjelaskan behavior ini pada Manage Relationships.

Troubleshooting: USERELATIONSHIP Error dengan RLS

Periksa apakah row-level security didefinisikan pada tabel yang terlibat dalam calculation.

Microsoft mendokumentasikan restriction USERELATIONSHIP pada kondisi RLS tertentu.

Jangan mencoba menyelesaikan security architecture hanya melalui formula DAX.

Best Practice 1: Active Relationship Sebanyak Mungkin

Microsoft merekomendasikan active relationships whenever possible.

Alasannya sederhana:

model lebih natural;

report authors mempunyai lebih banyak fleksibilitas;

Q&A lebih mudah memahami model;

dan RLS hanya dapat menggunakan active propagation paths.

Best Practice 2: Jadikan Role Paling Umum sebagai Active

Jika tetap menggunakan satu Date dimension:

tentukan role paling umum.

Misalnya:

OrderDate = active.

ShipDate = inactive.

DeliveryDate = inactive.

Jangan memilih secara acak.

Best Practice 3: Gunakan Base Measures

Gunakan:

Total Sales =
SUM(FactSales[SalesAmount])

kemudian:

Shipped Sales =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Ini lebih maintainable daripada mengulang aggregation logic.

Best Practice 4: Nama Measure Harus Menjelaskan Role

Jangan membuat:

Sales 1

Sales 2.

Gunakan:

Total Sales

Shipped Sales

Delivered Sales.

Business meaning harus terlihat langsung.

Best Practice 5: Pertimbangkan Duplicate Dimension Jika Role Digunakan Bersamaan

Jika report sering membutuhkan:

Order Month vs Ship Month;

Origin vs Destination;

Hire Date vs Termination Date,

duplicate role-playing dimensions sering menghasilkan semantic model yang lebih jelas.

Best Practice 6: Jangan Mengandalkan Inactive Relationships untuk RLS

Jika role tersebut harus membawa security filter:

gunakan active relationship architecture yang tepat.

Best Practice 7: Hide Technical Keys

Role-playing dimension dapat membuat Data pane semakin ramai.

Sembunyikan:

DateKey;

OrderDateKey;

ShipDateKey;

dan technical foreign keys yang tidak diperlukan report author.

Expose business-friendly attributes.

Best Practice 8: Dokumentasikan Active dan Inactive Paths

Untuk model besar, dokumentasikan:

relationship default;

alternative relationships;

measure yang menggunakan USERELATIONSHIP;

dan alasan desain.

Ini sangat membantu maintenance.

Decision Framework: Active, Inactive, atau Duplicate Dimension?

Tanyakan terlebih dahulu:

Apakah terdapat lebih dari satu relationship role antara dimension dan fact yang sama?

Jika tidak:

gunakan active relationship biasa.

Jika ya, tanyakan:

Apakah satu role jelas merupakan default dan role lainnya hanya sesekali digunakan?

Jika ya:

active + inactive + USERELATIONSHIP merupakan pilihan yang masuk akal.

Jika tidak, tanyakan:

Apakah report perlu memfilter atau grouping menggunakan beberapa role secara bersamaan?

Jika ya:

pertimbangkan duplicate role-playing dimension.

Kemudian tanyakan:

Apakah RLS bergantung pada relationship tersebut?

Jika ya:

utamakan active relationship design.

Quick Reference

Situasi	Rekomendasi Umum
Hanya satu Date role	Active relationship
OrderDate utama, ShipDate sesekali	OrderDate active, ShipDate inactive + USERELATIONSHIP
OrderDate dan ShipDate sering dipakai bersamaan	Pertimbangkan duplicate Date dimensions
Origin dan Destination selalu muncul bersamaan	Role-specific dimensions
Alternative relationship hanya untuk satu measure	USERELATIONSHIP
RLS harus melewati relationship	Active relationship
Relationship dashed tetapi valid	Inactive, bukan error
Visual menggunakan default calculation	Active relationship digunakan

FAQ: Active vs Inactive Relationship Power BI

Apa itu Active Relationship di Power BI?

Active Relationship adalah relationship yang secara default digunakan Power BI untuk filter propagation. Di Model View biasanya ditampilkan dengan garis solid.

Apa itu Inactive Relationship?

Inactive Relationship merupakan relationship yang tersimpan dalam semantic model tetapi tidak digunakan sebagai default filter path. Model View menampilkannya sebagai garis putus-putus.

Apakah inactive relationship berarti error?

Tidak. Inactive relationship merupakan relationship valid yang dapat digunakan calculation tertentu melalui USERELATIONSHIP.

Berapa active relationship yang boleh ada antara dua tabel?

Power BI hanya mengizinkan satu active filter propagation path sebagai default antara pasangan tabel ketika terdapat alternative relationships. Relationship tambahan harus inactive.

Apa itu USERELATIONSHIP?

USERELATIONSHIP adalah fungsi DAX yang menentukan existing relationship mana yang digunakan selama calculation tertentu dievaluasi.

Apakah USERELATIONSHIP membuat relationship baru?

Tidak. Relationship harus sudah ada dalam semantic model.

Apakah USERELATIONSHIP mengubah relationship menjadi active secara permanen?

Tidak. Relationship hanya digunakan selama calculation berlangsung.

Mengapa USERELATIONSHIP biasanya menggunakan CALCULATE?

Karena USERELATIONSHIP merupakan filter modifier yang mengubah relationship path yang digunakan ketika expression CALCULATE dievaluasi.

Apa contoh USERELATIONSHIP?

Sales by Ship Date =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Apakah OrderDate atau ShipDate sebaiknya active?

Role yang paling sering digunakan sebagai default analysis biasanya menjadi active. Microsoft menggunakan OrderDate sebagai active relationship dalam contoh resminya.

Apa itu role-playing dimension?

Role-playing dimension adalah dimension yang secara logis sama tetapi memainkan beberapa business role, seperti Date sebagai Order Date, Ship Date, dan Delivery Date.

Apakah lebih baik menggunakan USERELATIONSHIP atau duplicate Date table?

Jika alternative role hanya dibutuhkan calculation tertentu, USERELATIONSHIP dapat menjadi pilihan yang efisien. Jika beberapa role perlu digunakan bersamaan, atau RLS menjadi pertimbangan, role-specific duplicated dimensions sering lebih baik. Microsoft merekomendasikan active relationships whenever possible.

Apakah USERELATIONSHIP bekerja dengan RLS?

Ada batasan penting. RLS hanya dipropagasikan melalui active relationships, dan Microsoft juga mendokumentasikan restriction USERELATIONSHIP ketika RLS didefinisikan pada tabel tertentu.

Mengapa Date slicer menampilkan BLANK padahal ShipDate relationship inactive?

Karena table expansion dapat mempertimbangkan inactive relationships. BLANK ShipDate atau masalah referential integrity dapat menyebabkan BLANK member muncul.

Apa perbedaan USERELATIONSHIP dan CROSSFILTER?

USERELATIONSHIP memilih relationship mana yang digunakan. CROSSFILTER mengubah arah filter relationship selama calculation.

Apa perbedaan USERELATIONSHIP dan TREATAS?

USERELATIONSHIP menggunakan existing physical relationship. TREATAS menerapkan virtual filtering berdasarkan table expression dan tidak membutuhkan relationship fisik yang sama.

Kesimpulan

Active dan Inactive Relationship bukan sekadar perbedaan antara garis solid dan garis putus-putus pada Model View Power BI.

Keduanya menentukan relationship mana yang menjadi default filter propagation path dan relationship mana yang hanya digunakan untuk calculation khusus.

Active Relationship digunakan secara otomatis.

Jika DimDate mempunyai active relationship menuju FactSales[OrderDate], seluruh measure standar yang difilter DimDate akan secara default dianalisis berdasarkan Order Date.

Inactive Relationship tetap merupakan relationship yang valid, tetapi tidak digunakan sebagai default.

Untuk menggunakannya pada measure tertentu, DAX menyediakan:

USERELATIONSHIP.

Contohnya:

Sales by Ship Date =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(
        DimDate[Date],
        FactSales[ShipDate]
    )
)

Pattern ini sangat berguna untuk role-playing dimension seperti:

Order Date vs Ship Date;

Hire Date vs Termination Date;

Origin vs Destination;

Departure vs Arrival.

Namun inactive relationships tidak selalu merupakan desain terbaik.

Microsoft merekomendasikan penggunaan active relationships whenever possible karena active paths memberi fleksibilitas lebih besar bagi report author, Q&A, dan Row-Level Security. Ketika beberapa role dimension sering digunakan secara bersamaan, menduplikasi role-playing dimension dapat menghasilkan semantic model yang lebih jelas.

Hal lain yang sangat penting adalah bahwa RLS hanya dipropagasikan melalui active relationships. USERELATIONSHIP tidak membuat inactive relationship menjadi jalur RLS.

Karena itu prinsip desainnya bukan:

Gunakan inactive relationship sebanyak mungkin supaya tabel lebih sedikit.

Dan juga bukan:

Duplicate setiap dimension supaya semuanya active.

Prinsip yang lebih tepat adalah:

Jadikan relationship yang paling natural dan paling sering digunakan sebagai active. Gunakan USERELATIONSHIP untuk alternative path yang spesifik. Jika beberapa role harus digunakan secara independen atau bersamaan, pertimbangkan role-playing dimension terpisah.

Dengan memahami konsep ini, Anda tidak hanya memahami mengapa Power BI menggambar satu relationship menggunakan garis solid dan relationship lainnya dengan dashed line.

Anda juga mulai memahami sesuatu yang jauh lebih penting:

bagaimana Power BI memilih jalur filter yang menentukan konteks setiap angka pada dashboard Anda.

Referensi Utama

Microsoft Learn — Active vs inactive relationship guidance. Dokumentasi ini membahas OrderDate vs ShipDate, USERELATIONSHIP, role-playing dimension, table expansion, RLS, serta rekomendasi menggunakan active relationship whenever possible.

Microsoft Learn — Model relationships in Power BI Desktop. Dokumentasi ini menjelaskan active filter propagation paths, USERELATIONSHIP, relationship weight, ambiguity, dan relationship behavior.

Microsoft Learn — USERELATIONSHIP function (DAX). Dokumentasi ini membahas syntax, behavior, multiple USERELATIONSHIP calls, nesting, dan restrictions termasuk Row-Level Security.

Microsoft Learn — Understand star schema and the importance for Power BI. Dokumentasi ini membahas role-playing dimensions dan trade-off active versus inactive relationship.

Microsoft Learn — Create and Manage Relationships in Power BI Desktop. Dokumentasi ini menjelaskan bagaimana Power BI menentukan active relationship serta cara mengubah active dan inactive relationships.