Cross Filter Direction Power BI: Memahami Single vs Both secara Mendalam

Ketika belajar relationship di Power BI, sebagian besar pengguna pertama-tama fokus pada cardinality.

Kita belajar:

One-to-One (1:1), One-to-Many (1:*), Many-to-One (*:1), dan Many-to-Many (*:*).

Namun cardinality sebenarnya baru menjawab satu pertanyaan:

Bagaimana satu baris pada tabel pertama berhubungan dengan baris pada tabel kedua?

Masih ada pertanyaan lain yang sama pentingnya:

Ke arah mana filter boleh bergerak melalui relationship tersebut?

Jawaban pertanyaan kedua ditentukan oleh Cross Filter Direction.

Di sinilah kita mengenal dua konsep utama:

Single

dan:

Both.

Secara sederhana:

Single berarti filter bergerak dalam satu arah.

Both berarti filter dapat bergerak dalam kedua arah.

Namun dalam semantic modeling Power BI, perbedaannya jauh lebih penting daripada sekadar satu panah versus dua panah.

Cross Filter Direction memengaruhi:

filter context, slicer behavior, DAX calculation, dimension-to-dimension analysis, many-to-many modeling, performa query, ambiguity, Row-Level Security, dan kemampuan pengguna memahami bagaimana sebuah dashboard menghasilkan angka.

Microsoft menyarankan penggunaan bi-directional relationship secara terbatas. Alasannya adalah relationship dua arah dapat meningkatkan pemrosesan query dan menciptakan pengalaman yang membingungkan ketika filter dapat bergerak melalui beberapa jalur berbeda.

Karena itu, artikel ini akan membahas Cross Filter Direction dari dasar hingga advanced, termasuk bagaimana Single dan Both bekerja, apa hubungannya dengan star schema, kapan Both benar-benar diperlukan, mengapa Both tidak sebaiknya menjadi default, bagaimana menggunakan CROSSFILTER dalam DAX, dan bagaimana mendiagnosis masalah filter propagation dalam model Power BI.

Apa Itu Cross Filter Direction di Power BI?

Cross Filter Direction adalah properti relationship yang menentukan arah filter context dapat dipropagasikan dari satu tabel menuju tabel lain.

Bayangkan terdapat dua tabel:

DimProduct

dan:

FactSales.

Relationship:

DimProduct 1 → * FactSales

Jika relationship menggunakan Single direction, filter bergerak:

DimProduct → FactSales

Ketika pengguna memilih:

Category = Hair Care

Power BI memfilter DimProduct terlebih dahulu.

Kemudian filter tersebut bergerak melalui relationship menuju FactSales.

FactSales akhirnya hanya berisi transaksi produk Hair Care dalam filter context calculation.

Cross Filter Direction Bukan Cardinality

Cardinality dan Cross Filter Direction adalah dua konsep berbeda.

Cardinality menjelaskan:

Bagaimana jumlah row kedua tabel berhubungan?

Sementara Cross Filter Direction menjelaskan:

Ke arah mana filter bergerak?

Contoh:

DimProduct 1 → * FactSales

Cardinality:

One-to-Many.

Cross Filter Direction:

Single.

Atau relationship yang sama dapat dikonfigurasi:

DimProduct 1 ↔ * FactSales

Cardinality tetap:

One-to-Many.

Tetapi Cross Filter Direction berubah menjadi:

Both.

Apa Itu Filter Propagation?

Filter propagation adalah proses ketika filter context dari sebuah tabel diteruskan melalui relationship menuju tabel yang berhubungan.

Misalnya:

DimProduct memiliki:

ProductID	Product	Category
P001	Shampoo A	Hair Care
P002	Shampoo B	Hair Care
P003	Soap A	Personal Care

FactSales:

SalesID	ProductID	Quantity	SalesAmount
S001	P001	5	250000
S002	P002	7	350000
S003	P003	3	120000

Jika pengguna memilih:

Category = Hair Care

DimProduct menjadi:

P001

P002.

Relationship kemudian meneruskan filter tersebut ke FactSales.

FactSales efektif menjadi:

S001

S002.

SalesAmount yang dihitung:

250000 + 350000 = 600000.

Inilah filter propagation.

Apa Itu Single Cross Filter Direction?

Single berarti relationship meneruskan filter hanya dalam satu arah.

Dalam relationship one-to-many:

Dimension 1 → * Fact

arah Single bergerak dari sisi one menuju sisi many.

Microsoft menjelaskan bahwa ketika cardinality mempunyai sisi one, filter selalu dapat bergerak dari sisi tersebut. Dalam one-to-many, pilihan Single berarti filter bergerak dari sisi one menuju sisi many.

Secara sederhana:

Dimension → Fact

Contoh Single Direction

Misalnya:

DimCustomer 1 → * FactSales

Ketika user memilih:

Customer = ABC Store

FactSales difilter hanya untuk transaksi ABC Store.

Namun filter dari FactSales tidak otomatis mengalir kembali menuju DimCustomer untuk kemudian memfilter dimension lain.

Inilah karakter Single.

Mengapa Single Direction Sangat Cocok dengan Star Schema?

Dalam star schema, tabel mempunyai peran yang jelas.

Dimension menyediakan:

filtering;

grouping;

hierarchy;

dan business context.

Fact menyediakan:

transactions;

observations;

dan measurements.

Maka aliran filter yang natural adalah:

Dimension → Fact.

Misalnya:

DimDate → FactSales

DimProduct → FactSales

DimCustomer → FactSales

DimStore → FactSales.

Semua dimension memfilter fact.

Fact tidak perlu memfilter balik dimension untuk sebagian besar analytical queries.

Contoh Star Schema dengan Single Direction

Model:

DimDate 1 → * FactSales

DimProduct 1 → * FactSales

DimCustomer 1 → * FactSales

DimStore 1 → * FactSales

Pengguna memilih:

Year = 2026

Category = Hair Care

Region = Jakarta.

Ketiga filter bergerak menuju FactSales.

FactSales kemudian berisi intersection dari seluruh kondisi tersebut.

Measure:

Total Sales =
SUM(FactSales[SalesAmount])

menghitung hanya transaksi yang memenuhi ketiga kondisi.

Mengapa Single Biasanya Menjadi Best Practice?

Single direction mempunyai beberapa keuntungan penting.

Pertama, filter flow mudah dipahami.

Developer dapat melihat model dan langsung mengetahui:

Dimension memfilter Fact.

Kedua, filter path lebih mudah diprediksi.

Ketiga, risiko ambiguity lebih rendah.

Keempat, processing relationship biasanya lebih sederhana dibandingkan banyak bidirectional relationships.

Kelima, semantic model lebih mudah dijelaskan kepada developer lain.

Microsoft menyebut Single sebagai arah yang paling umum dan merekomendasikan agar penggunaan relationship bidirectional diminimalkan.

Apa Itu Both Cross Filter Direction?

Both berarti filter dapat bergerak melalui relationship dalam kedua arah.

Misalnya:

DimProduct 1 ↔ * FactSales

Filter dari DimProduct dapat memfilter FactSales.

Tetapi filter pada FactSales juga dapat memengaruhi DimProduct.

Relationship semacam ini disebut:

bi-directional relationship.

Contoh Both Direction

Bayangkan terdapat:

DimCustomer

FactSales

DimProduct.

Relationship:

DimCustomer 1 ↔ * FactSales

DimProduct 1 ← * FactSales.

Ketika Customer tertentu dipilih:

Customer memfilter Sales.

Karena relationship Customer–Sales bersifat Both, context dapat melewati FactSales dan dalam desain tertentu akhirnya memengaruhi dimension lain.

Dengan cara ini kita dapat melakukan analysis antar dimension melalui fact table.

Single vs Both secara Sederhana

Aspek	Single	Both
Arah filter	Satu arah	Dua arah
Nama lain	Single-direction	Bidirectional
Star schema standar	Sangat cocok	Gunakan bila diperlukan
Kompleksitas	Lebih rendah	Lebih tinggi
Risiko ambiguity	Lebih rendah	Lebih tinggi
Processing filter	Lebih sederhana	Dapat membutuhkan lebih banyak processing
Dimension-to-dimension analysis	Tidak langsung	Dapat memungkinkan

Bagaimana Cross Filter Direction Ditampilkan di Model View?

Model View Power BI memberikan indikator visual pada garis relationship.

Satu arrow menunjukkan:

Single direction.

Double arrow menunjukkan:

Both direction.

Microsoft menyarankan membaca arrowhead pada relationship line untuk memahami bagaimana filter context bergerak di dalam model.

Ini adalah salah satu hal pertama yang sebaiknya diperiksa ketika visual tidak menghasilkan angka sesuai ekspektasi.

Cross Filter Direction dan Cardinality

Tidak semua cardinality mempunyai pilihan cross-filter yang sama.

Cardinality	Cross Filter Direction
One-to-Many	Single atau Both
Many-to-One	Single atau Both
One-to-One	Both
Many-to-Many	Single dari salah satu sisi atau Both

One-to-one selalu bidirectional.

One-to-many dapat menggunakan Single atau Both.

Many-to-many lebih fleksibel karena tidak mempunyai guaranteed one side.

Kenapa One-to-One Selalu Both?

Relationship 1:1 mempunyai nilai unik pada kedua sisi.

Power BI memperlakukan relationship tersebut dengan cross filter Both.

Ini bukan opsi yang dapat diubah menjadi Single dalam konfigurasi relationship biasa.

Karena itu, seperti dibahas pada artikel One-to-One sebelumnya, keputusan pentingnya bukan:

Haruskah arah filter saya Single atau Both?

Melainkan:

Apakah kedua tabel ini memang perlu tetap dipisahkan?

Kapan Both Direction Dibutuhkan?

Microsoft mengidentifikasi beberapa skenario utama di mana bidirectional filtering dapat membantu.

Salah satunya adalah special model relationship seperti one-to-one dan many-to-many melalui bridging table.

Skenario lain adalah membuat slicer menampilkan hanya pilihan yang memiliki data.

Skenario ketiga adalah dimension-to-dimension analysis, ketika filter dari satu dimension perlu mencapai dimension lain melalui fact table.

Skenario 1: Many-to-Many melalui Bridge Table

Misalnya:

Customer dapat mempunyai banyak Account.

Account dapat dimiliki banyak Customer.

Model:

DimCustomer

BridgeCustomerAccount

DimAccount

FactTransaction.

Agar Customer dapat memfilter Account dan akhirnya Transaction, filter harus dapat melewati bridge table.

Pada desain tertentu, paling tidak satu relationship perlu memungkinkan bidirectional filter propagation.

Inilah salah satu skenario di mana Both merupakan bagian dari solusi modeling, bukan sekadar convenience.

Skenario 2: Slicer “With Data”

Misalnya terdapat:

DimCustomer

DimProduct

FactSales.

Customer dan Product masing-masing mempunyai relationship Single menuju Sales.

User memilih:

Country = Australia.

Product slicer masih dapat menampilkan seluruh produk, termasuk produk yang belum pernah dijual di Australia.

Jika relationship Product–Sales dibuat Both, filter Australia:

Customer

→ Sales

→ Product

sehingga Product slicer dapat menampilkan hanya produk yang mempunyai sales di Australia.

Microsoft menyebut pola ini sebagai slicer options “with data”.

Apakah Microsoft Merekomendasikan Both untuk Slicer “With Data”?

Menariknya, meskipun Both dapat menyelesaikan kebutuhan tersebut, Microsoft tidak menyarankan menjadikan bi-directional relationship sebagai solusi utama untuk kebutuhan slicer “with data”.

Alasannya:

lebih banyak processing;

dapat memengaruhi query performance;

dan pilihan slicer yang tiba-tiba hilang atau muncul dapat membingungkan report user.

Alternatif yang direkomendasikan adalah menggunakan measure sebagai visual-level filter pada slicer.

Misalnya:

Total Quantity =
SUM(FactSales[Quantity])

Kemudian pada Product slicer:

gunakan visual filter:

Total Quantity is not blank.

Dengan pendekatan tersebut, relationship model dapat tetap Single.

Mengapa UX Slicer Perlu Dipikirkan?

Bayangkan Product slicer awalnya menampilkan:

Shampoo

Soap

Toothpaste

Lotion.

User kemudian memilih Region = Jakarta.

Tiba-tiba Product slicer hanya menampilkan:

Shampoo

Soap.

Developer mungkin menganggap ini sangat pintar.

Namun user mungkin bertanya:

Ke mana Toothpaste dan Lotion pergi?

Filtering yang technically clever belum tentu menghasilkan UX yang lebih jelas.

Skenario 3: Dimension-to-Dimension Analysis

Ini merupakan salah satu alasan paling menarik menggunakan bidirectional filtering.

Misalnya terdapat:

DimCustomer

FactSales

DimProduct.

Anda ingin menjawab:

Berapa banyak negara yang membeli produk tertentu?

Perhatikan bahwa calculation yang ingin dihitung berasal dari:

DimCustomer[Country]

sedangkan grouping berasal dari:

DimProduct[Product].

Untuk Product memengaruhi Customer:

filter harus bergerak:

Product → Sales → Customer.

Dengan pure Single relationships:

Product → Sales

dan:

Customer → Sales,

filter Product berhenti pada Sales.

Filter tidak dapat bergerak “naik” menuju Customer.

Contoh Pertanyaan Dimension-to-Dimension

Beberapa pertanyaan bisnis yang membutuhkan pola serupa adalah:

Berapa customer yang membeli Product A?

Berapa negara yang membeli Category B?

Berapa salesperson yang pernah menjual Brand C?

Berapa store yang menjual Product D?

Berapa supplier yang memasok category tertentu?

Pertanyaan tersebut menghitung atribut dari dimension dalam context dimension lain.

Haruskah Model Diubah Menjadi Both untuk Pertanyaan Tersebut?

Tidak selalu.

Microsoft justru menyarankan mempertimbangkan penggunaan CROSSFILTER dalam measure sehingga bidirectional filtering hanya aktif ketika calculation tertentu dievaluasi.

Ini mempertahankan model relationship tetap sederhana dengan Single direction.

Apa Itu CROSSFILTER?

CROSSFILTER adalah fungsi DAX yang dapat mengubah arah cross filtering sebuah relationship selama calculation sedang dievaluasi.

Relationship fisik di model tidak perlu diubah.

Contoh:

Different Countries Sold =
CALCULATE(
    DISTINCTCOUNT(DimCustomer[Country]),
    CROSSFILTER(
        DimCustomer[CustomerID],
        FactSales[CustomerID],
        BOTH
    )
)

Relationship Customer–Sales dapat tetap Single pada model.

Namun ketika measure tersebut dihitung, DAX untuk sementara memperlakukan relationship tersebut sebagai Both.

Mengapa CROSSFILTER Menarik?

Misalnya 95% calculation hanya membutuhkan:

Dimension → Fact.

Hanya satu measure membutuhkan:

Fact → Dimension.

Jika relationship diubah menjadi Both secara permanen, seluruh model membayar kompleksitas tersebut.

Dengan CROSSFILTER:

Both hanya aktif untuk calculation yang benar-benar membutuhkannya.

Inilah prinsip penting:

Gunakan scope sekecil mungkin untuk complexity.

CROSSFILTER Tidak Mengubah Model Secara Permanen

Ini perlu ditekankan.

Jika Model View menunjukkan:

DimCustomer → FactSales

relationship tersebut tetap Single.

CROSSFILTER hanya mengubah bagaimana relationship dievaluasi selama execution measure.

Setelah calculation selesai, relationship kembali mengikuti configuration model.

Direction yang Didukung CROSSFILTER

DAX CROSSFILTER dapat mengatur behavior seperti:

Both;

None;

OneWay;

dan direction-specific options tertentu pada relationship many-to-many.

Dengan kata lain CROSSFILTER tidak hanya dapat membuat relationship sementara menjadi Both.

Ia juga dapat menonaktifkan filter propagation untuk calculation tertentu.

Contoh Menggunakan CROSSFILTER(None)

Misalnya relationship tertentu tidak ingin digunakan pada calculation:

Special Measure =
CALCULATE(
    [Total Sales],
    CROSSFILTER(
        DimProduct[ProductID],
        FactSales[ProductID],
        NONE
    )
)

Untuk evaluation measure tersebut, filter tidak dipropagasikan melalui relationship yang ditentukan.

Cross Filter Direction dan DAX Filter Context

Untuk memahami Single dan Both dengan baik, kita perlu memahami hubungan dengan filter context.

Misalnya:

Total Sales =
SUM(FactSales[SalesAmount])

User memilih:

Category = Hair Care.

Filter context dibuat pada DimProduct.

Relationship kemudian menentukan:

Apakah context tersebut dapat mencapai FactSales?

Jika ya, Total Sales berubah.

Jika tidak ada filter path, Total Sales tetap menghitung data yang tidak terfilter oleh Category.

Relationship Adalah Jalur Filter Context

Salah satu cara terbaik memahami Power BI adalah membayangkan relationship sebagai jalan.

Filter context adalah kendaraan.

Cross Filter Direction menentukan arah lalu lintas.

Single:

jalan satu arah.

Both:

jalan dua arah.

Jika model mempunyai banyak jalan dua arah dan banyak persimpangan, semakin sulit menentukan rute filter yang akan dilalui.

Itulah sebabnya ambiguity menjadi masalah.

Apa Itu Ambiguous Filter Path?

Ambiguity terjadi ketika filter mempunyai lebih dari satu jalur yang valid untuk mencapai tabel target.

Misalnya terdapat:

DimProduct

FactSales

DimCustomer

FactBudget

dan beberapa relationship Both.

Filter Product mungkin dapat mencapai tabel tertentu melalui:

Path A

atau:

Path B.

Power BI kemudian harus menentukan jalur mana yang seharusnya digunakan.

Dalam beberapa konfigurasi Power BI menolak relationship change karena akan menghasilkan ambiguous propagation path.

Contoh Ambiguity Sederhana

Bayangkan:

Table A ↔ Table B

Table B ↔ Table D

Table A ↔ Table C

Table C ↔ Table D.

Filter dari A menuju D dapat berjalan:

A → B → D

atau:

A → C → D.

Jika kedua path aktif dan valid, interpretasi model menjadi jauh lebih kompleks.

Kenapa Both Meningkatkan Risiko Ambiguity?

Single direction membatasi jumlah rute.

Misalnya:

Dimension → Fact.

Filter tidak dapat kembali naik ke dimension lain.

Ketika relationship dibuat Both, jumlah possible filter paths meningkat.

Semakin besar semantic model, semakin besar risiko loop dan multiple routes.

Masalah Both pada Multiple Fact Tables

Misalnya terdapat:

DimProduct

FactSales

FactBudget.

Product memfilter Sales.

Product juga memfilter Budget.

Ini normal.

Tetapi jika semua relationship dibuat Both, Sales dapat mulai memengaruhi Product, kemudian Product memengaruhi Budget.

Dengan kata lain:

FactSales dapat secara tidak langsung memfilter FactBudget.

Apakah itu selalu business behavior yang diinginkan?

Tidak.

Itulah mengapa Microsoft menyarankan menghindari Both secara sembarangan ketika beberapa fact table berbagi lookup/dimension.

Contoh Sales dan Budget

Model:

DimDepartment → FactSales

DimDepartment → FactBudget.

Pengguna memfilter FactSales.

Jika relationships Single:

Sales tidak memfilter Department.

Budget tetap tidak terpengaruh oleh kondisi Sales.

Jika Both digunakan:

Sales dapat memfilter Department.

Department kemudian dapat memfilter Budget.

Anda telah menciptakan:

Fact-to-Dimension-to-Fact propagation.

Dalam banyak kasus business behavior tersebut tidak diinginkan.

Both dan Performance

Microsoft secara khusus memperingatkan bahwa relationship bidirectional dapat berdampak negatif terhadap query performance.

Mengapa?

Karena engine memiliki lebih banyak filter propagation yang perlu dievaluasi.

Semakin banyak Both relationships, semakin kompleks dependency dan filter paths.

Performance impact bukan berarti satu relationship Both pasti membuat report lambat.

Namun pada model besar, penggunaan Both yang berlebihan dapat memperbesar query complexity.

Apakah Single Selalu Lebih Cepat?

Tidak tepat membuat aturan absolut:

Single selalu cepat.

Both selalu lambat.

Performance bergantung pada banyak faktor:

jumlah row;

cardinality;

DAX;

storage mode;

filter selectivity;

jumlah visuals;

relationship topology;

dan data source.

Namun Single menghasilkan architecture yang lebih sederhana dan karena itu merupakan baseline yang lebih aman.

Gunakan Performance Analyzer

Jika Anda mempertimbangkan mengubah relationship menjadi Both demi sebuah report requirement:

ukur performanya.

Gunakan:

Performance Analyzer.

Bandingkan:

sebelum Both;

setelah Both;

atau setelah menggunakan measure dengan CROSSFILTER.

Gunakan data nyata, bukan asumsi.

Both dan User Experience

Masalah Both tidak selalu teknis.

Ia juga dapat memengaruhi user experience.

Misalnya slicer Product berubah berdasarkan Customer.

Kemudian Customer berubah berdasarkan Region.

Kemudian Region options berubah berdasarkan Product.

Bagi developer ini mungkin terlihat sangat interconnected.

Bagi pengguna:

model dapat terasa seperti slicer yang “menghilangkan pilihan sendiri”.

Microsoft memperingatkan bahwa report users dapat merasa bingung ketika slicer values muncul dan menghilang akibat bidirectional filtering.

Single Menghasilkan Mental Model yang Lebih Sederhana

User memilih Dimension.

Dimension memfilter measure.

Selesai.

Contoh:

pilih Product;

Sales berubah.

pilih Customer;

Sales berubah.

pilih Date;

Sales berubah.

Model sederhana biasanya menghasilkan dashboard yang lebih mudah dipercaya.

Cross Filter Direction dan Row-Level Security

Cross filter direction juga memiliki hubungan dengan Row-Level Security atau RLS.

Ketika relationship diatur Both, Power BI dapat menyediakan opsi terkait penerapan security filter dalam kedua arah.

Namun security propagation harus dirancang dengan sangat hati-hati.

Jangan menganggap bidirectional RLS sama dengan bidirectional reporting filter biasa.

Security logic harus diuji berdasarkan role dan actual user scenario.

Apply Security Filter in Both Directions

Pada relationship tertentu, Power BI menyediakan opsi:

Apply security filter in both directions.

Tujuannya adalah memungkinkan RLS filter dipropagasikan melalui relationship ke arah lain.

Pengaturan ini hanya seharusnya digunakan ketika security model memang membutuhkannya.

Security model yang salah tidak hanya menghasilkan angka salah, tetapi dapat menyebabkan data terlihat oleh user yang tidak seharusnya melihatnya.

Cross Filter Direction dan Active Relationship

Cross Filter Direction tidak sama dengan Active Relationship.

Relationship dapat:

aktif + Single;

aktif + Both;

inactive;

dan kemudian diaktifkan secara calculation-specific menggunakan USERELATIONSHIP.

Active menentukan relationship default yang digunakan.

Cross Filter Direction menentukan arah filter pada relationship tersebut.

Single dan USERELATIONSHIP

Misalnya:

DimDate → FactSales[OrderDate]

aktif.

DimDate → FactSales[ShipDate]

inactive.

Measure:

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

USERELATIONSHIP memilih relationship.

CROSSFILTER mengubah filter direction.

Keduanya mempunyai tujuan berbeda.

USERELATIONSHIP vs CROSSFILTER

Function	Tujuan
USERELATIONSHIP	Menggunakan inactive relationship untuk calculation
CROSSFILTER	Mengubah arah atau menonaktifkan filter propagation

Keduanya dapat digunakan di dalam CALCULATE.

Contoh Dimension-to-Dimension dengan CROSSFILTER

Misalnya:

DimCustomer → FactSales ← DimProduct.

Kita ingin menghitung:

jumlah customer yang membeli setiap product.

Measure:

Customers Purchased =
CALCULATE(
    DISTINCTCOUNT(DimCustomer[CustomerID]),
    CROSSFILTER(
        DimCustomer[CustomerID],
        FactSales[CustomerID],
        BOTH
    )
)

Ketika Product A menjadi row visual:

Product memfilter FactSales.

CROSSFILTER memungkinkan FactSales memfilter kembali Customer.

DISTINCTCOUNT kemudian menghitung hanya customer yang mempunyai transaksi Product A.

Tanpa CROSSFILTER Apa yang Terjadi?

Jika Customer–Sales tetap Single:

Customer → Sales.

Filter dari Product mencapai Sales.

Tetapi berhenti di Sales.

DimCustomer tidak ikut terfilter.

DISTINCTCOUNT(CustomerID) mungkin menghasilkan total customer yang sama pada setiap product.

Ini sering membuat pengguna menganggap DAX-nya salah.

Padahal sumber persoalannya adalah filter propagation.

Troubleshooting: Angka Sama pada Setiap Row

Ini merupakan gejala klasik filter tidak mencapai tabel yang dihitung.

Misalnya visual:

Product	Customer Count
Product A	10,000
Product B	10,000
Product C	10,000

Jika 10.000 adalah total seluruh customer, kemungkinan Product context tidak dapat mencapai DimCustomer.

Periksa filter path.

Troubleshooting Checklist untuk Filter Direction

Ketika filter tidak bekerja seperti yang diharapkan, periksa:

relationship ada atau tidak;

relationship aktif atau inactive;

arrow direction;

cardinality;

relationship key;

data type key;

matching key values;

dan apakah filter path memang memungkinkan context mencapai tabel target.

Microsoft juga menempatkan filter direction sebagai salah satu hal utama yang harus diverifikasi saat troubleshooting relationship.

Troubleshooting: Slicer Tidak Memfilter Slicer Lain

Ini tidak otomatis berarti model salah.

Dalam star schema dengan Single relationships:

Customer → Sales ← Product.

Customer slicer memfilter Sales.

Namun tidak memfilter Product.

Itu adalah expected behavior.

Jika Anda memang ingin Product slicer hanya menampilkan produk yang dibeli Customer tersebut, gunakan teknik slicer “with data” atau solusi calculation-specific.

Troubleshooting: Both Tidak Bisa Diaktifkan

Power BI dapat menolak konfigurasi Both jika relationship baru menghasilkan ambiguous filter paths.

Jika ini terjadi, jangan mencoba memaksa model.

Periksa topology relationship.

Anda mungkin perlu:

menghapus relationship yang tidak diperlukan;

membuat relationship inactive;

mengubah Both menjadi Single;

atau mendesain ulang dimension role.

Troubleshooting: Report Berubah Setelah Mengaktifkan Both

Both dapat membuat filter mencapai tabel yang sebelumnya tidak terfilter.

Akibatnya:

measure;

slicer;

visual totals;

dan options

dapat berubah.

Jangan hanya mengecek apakah visual yang Anda ingin perbaiki sekarang benar.

Regression-test seluruh report.

Both Bukan “Lebih Powerful” dari Single

Ini persepsi yang cukup umum.

Single dianggap:

versi sederhana.

Both dianggap:

versi advanced dan lebih bagus.

Itu keliru.

Single dan Both mempunyai tujuan berbeda.

Relationship terbaik bukan relationship yang memiliki filter paling banyak.

Relationship terbaik adalah relationship yang hanya memberikan filter propagation yang memang dibutuhkan business model.

Analogi Pintu

Bayangkan dua ruangan terhubung pintu.

Single seperti pintu satu arah.

Orang dari A dapat masuk B.

Orang dari B tidak dapat kembali A melalui pintu tersebut.

Both seperti pintu dua arah.

Keduanya bisa saling masuk.

Apakah pintu dua arah selalu lebih baik?

Tidak.

Pada sistem lalu lintas kompleks, arah yang dikontrol justru membuat aliran lebih mudah dipahami.

Analogi Jalan Tol

Single:

jalan menuju fact.

Dimension merupakan pintu masuk.

Fact adalah pusat transaksi.

Both:

jalan dapat digunakan pulang-pergi.

Jika hanya satu jalan, masih sederhana.

Namun jika terdapat puluhan jalan dua arah yang saling terhubung:

routing menjadi kompleks.

Ini menggambarkan ambiguity dalam semantic model.

Best Practice 1: Mulai dengan Single

Untuk star schema standar:

gunakan:

Dimension → Fact.

Jadikan Single sebagai baseline.

Jangan mengubah menjadi Both sampai Anda mempunyai requirement yang jelas.

Best Practice 2: Tanyakan Mengapa Both Dibutuhkan

Sebelum mengubah setting:

tanyakan:

Calculation atau behavior apa yang tidak dapat diselesaikan dengan Single?

Jika jawabannya tidak jelas:

jangan gunakan Both.

Best Practice 3: Pertimbangkan CROSSFILTER

Jika hanya satu atau dua measure membutuhkan reverse propagation:

pertimbangkan CROSSFILTER.

Relationship model tetap sederhana.

Complexity ditempatkan pada calculation yang memang memerlukannya.

Best Practice 4: Jangan Gunakan Both Hanya untuk Slicer

Jika tujuan hanya membuat slicer menampilkan option “with data”:

pertimbangkan visual-level measure filter.

Ini sering lebih aman daripada mengubah semantic relationship seluruh model.

Best Practice 5: Periksa Shared Dimensions

Jika satu dimension terhubung ke:

FactSales

dan:

FactBudget,

hindari membuat semua relationship Both tanpa alasan kuat.

Pastikan FactSales tidak secara tidak sengaja mulai memfilter FactBudget melalui dimension.

Best Practice 6: Dokumentasikan Both Relationships

Jika model memang membutuhkan Both:

dokumentasikan alasan bisnisnya.

Misalnya:

Bridge Customer–Account requires reverse propagation.

Atau:

Used for RLS propagation.

Atau:

Used specifically for dimension-to-dimension analysis.

Developer berikutnya tidak perlu menebak.

Best Practice 7: Audit Model View

Secara berkala lihat Model View.

Jika hampir setiap relationship mempunyai double arrow:

lakukan review.

Model semacam itu mungkin benar.

Tetapi juga merupakan red flag yang layak diselidiki.

Best Practice 8: Star Schema Lebih Dahulu

Sebelum menggunakan Both untuk memperbaiki filter:

pastikan problem tidak sebenarnya disebabkan oleh model yang belum berbentuk star schema.

Jangan gunakan bidirectional filtering untuk menutupi model dimensional yang buruk.

Contoh FMCG

Bayangkan distributor mempunyai model:

DimDate

DimProduct

DimOutlet

DimSalesman

FactSales.

Relationship:

DimDate → FactSales

DimProduct → FactSales

DimOutlet → FactSales

DimSalesman → FactSales.

Semua Single.

Ini sudah cukup untuk:

Sales by Month;

Sales by Product;

Sales by Outlet;

Sales by Salesman;

Sales by Category;

Sales by Region.

Tidak ada alasan membuat Both hanya karena Power BI menyediakan opsinya.

Contoh Analisis Outlet yang Menjual Product

Sekarang pertanyaan berubah:

Berapa outlet unik yang membeli masing-masing product?

DimProduct memfilter FactSales.

Kita ingin menghitung distinct outlet dari DimOutlet.

Filter Product perlu mencapai Outlet melalui Sales.

Daripada mengubah Outlet–Sales menjadi Both secara permanen:

Outlets Buying Product =
CALCULATE(
    DISTINCTCOUNT(DimOutlet[OutletID]),
    CROSSFILTER(
        DimOutlet[OutletID],
        FactSales[OutletID],
        BOTH
    )
)

Relationship fisik tetap Single.

Contoh Salesman yang Menjual Brand

Pertanyaan:

Berapa salesperson yang pernah menjual Brand A?

Brand berada pada DimProduct.

Salesperson berada pada DimSalesman.

FactSales menjadi jembatan analytical.

Product → Sales harus kemudian mencapai Salesman.

CROSSFILTER dapat dipakai pada Salesman–Sales untuk calculation tersebut.

Contoh Region dan Product Availability

Pertanyaan:

Product apa saja yang benar-benar pernah terjual di Region tertentu?

Region memfilter Outlet.

Outlet memfilter Sales.

Sales perlu kemudian memfilter Product agar Product slicer menampilkan products with data.

Ini merupakan contoh classic bidirectional requirement.

Namun sekali lagi:

pertimbangkan apakah Anda benar-benar perlu mengubah model relationship atau cukup menggunakan visual filter.

Red Flags Penggunaan Both

Review model jika Anda menemukan kondisi berikut:

hampir seluruh relationship Both;

Both dipilih karena “biar aman”;

developer tidak dapat menjelaskan arah filter;

slicer values sering hilang tanpa user memahami sebabnya;

model mempunyai banyak loops;

multiple fact tables saling memfilter secara tidak langsung;

angka berubah setelah relationship lain ditambahkan;

atau DAX sangat bergantung pada accidental filter propagation.

Decision Framework: Single atau Both?

Tanyakan:

Apakah dimension hanya perlu memfilter fact?

Jika ya:

Single.

Tanyakan:

Apakah fact perlu memfilter kembali dimension untuk kebutuhan analysis tertentu?

Jika tidak:

Single.

Jika ya:

tanyakan lagi:

Apakah requirement hanya dibutuhkan oleh satu calculation?

Jika ya:

Pertimbangkan CROSSFILTER.

Jika requirement merupakan behavior fundamental seluruh model:

Both mungkin tepat.

Terakhir:

Apakah Both menciptakan ambiguity atau fact-to-fact propagation yang tidak diinginkan?

Jika ya:

desain ulang.

Single vs Both: Quick Reference

Situasi	Pilihan Umum
Dimension → Fact standard star schema	Single
Product filters Sales	Single
Customer filters Orders	Single
Date filters multiple fact tables	Single
One-to-One relationship	Both, mandatory
Bridge-table many-to-many pattern	May require Both on a relationship
Dimension-to-dimension calculation	Consider CROSSFILTER
Slicer showing only values with data	Prefer measure filter before global Both
Multiple shared fact tables	Generally avoid unnecessary Both
RLS reverse security propagation	Evaluate carefully

FAQ: Cross Filter Direction Power BI

Apa itu Cross Filter Direction Power BI?

Cross Filter Direction menentukan arah filter context dipropagasikan melalui relationship antar tabel dalam semantic model Power BI.

Apa perbedaan Single dan Both?

Single memungkinkan filter bergerak satu arah. Both memungkinkan filter bergerak dalam dua arah dan dikenal sebagai bidirectional filtering.

Mana yang lebih baik, Single atau Both?

Tidak ada yang selalu lebih baik. Namun untuk star schema standar, Single biasanya merupakan baseline yang paling sederhana dan aman. Both digunakan ketika business requirement memang membutuhkan reverse filter propagation.

Apakah Single merupakan default?

Single merupakan arah yang paling umum untuk relationship standar, khususnya one-to-many dari dimension menuju fact.

Apakah Both memperlambat Power BI?

Bidirectional filtering dapat menambah query processing dan Microsoft memperingatkan bahwa penggunaannya dapat berdampak negatif pada performance, terutama jika banyak relationship di model bersifat bidirectional.

Apakah Both dapat menyebabkan angka salah?

Both tidak otomatis menghasilkan angka salah. Namun filter dapat mencapai tabel melalui jalur yang sebelumnya tidak tersedia, sehingga calculation behavior dapat berubah. Multiple filter paths juga dapat menyebabkan ambiguity.

Apa itu ambiguous filter path?

Ambiguity terjadi ketika filter mempunyai lebih dari satu jalur relationship yang valid untuk mencapai tabel lain.

Apakah One-to-One selalu Both?

Ya. Relationship one-to-one menggunakan bidirectional filtering dan tidak dapat dikonfigurasi menjadi Single dalam relationship biasa.

Apakah Many-to-Many harus Both?

Tidak selalu. Cross-filter option untuk many-to-many dapat bergerak dari salah satu sisi maupun Both. Bridge-table design tertentu memerlukan bidirectional filtering agar filter dapat melewati bridge.

Apakah saya harus membuat Both agar slicer saling memfilter?

Tidak selalu. Microsoft menyarankan mempertimbangkan visual-level filter menggunakan measure untuk kebutuhan slicer “with data” agar relationship global dapat tetap Single.

Apa itu CROSSFILTER?

CROSSFILTER adalah fungsi DAX yang mengubah arah filter sebuah relationship selama evaluation calculation tertentu.

Apakah CROSSFILTER mengubah relationship permanen?

Tidak. Perubahan direction hanya berlaku selama measure atau expression tersebut dievaluasi.

Apa perbedaan CROSSFILTER dan USERELATIONSHIP?

CROSSFILTER mengubah arah filter relationship. USERELATIONSHIP mengaktifkan relationship tertentu—biasanya inactive relationship—selama sebuah calculation.

Kenapa angka Customer Count sama di semua Product?

Kemungkinan Product filter mencapai FactSales tetapi tidak dapat meneruskan filter ke DimCustomer karena relationship Customer–Sales hanya bergerak dari Customer menuju Sales. Gunakan desain atau calculation yang memungkinkan filter propagation yang sesuai.

Kenapa Power BI tidak mengizinkan Both?

Salah satu kemungkinan adalah konfigurasi Both akan menciptakan ambiguous filter propagation path.

Apakah Both cocok untuk multiple fact tables?

Gunakan dengan sangat hati-hati. Jika dimension bersama memfilter beberapa fact table, Both dapat menyebabkan satu fact memfilter fact lain secara tidak langsung melalui dimension.

Kesimpulan

Cross Filter Direction adalah salah satu konsep paling fundamental tetapi juga paling sering disalahgunakan dalam Power BI data modeling.

Cardinality menjelaskan hubungan:

1:1, 1:*, *:1, atau *:*.

Namun Cross Filter Direction menentukan:

Ke mana filter context boleh bergerak melalui relationship tersebut?

Pada Single, filter hanya bergerak satu arah.

Dalam star schema standar, pola yang paling umum adalah:

Dimension → Fact.

Ini menghasilkan model yang:

mudah dipahami;

mudah diprediksi;

lebih kecil risiko ambiguity-nya;

dan biasanya lebih mudah dipelihara.

Pada Both, filter bergerak dua arah.

Bidirectional filtering dapat menjadi solusi yang tepat untuk beberapa kebutuhan khusus seperti:

special relationships;

bridge-table many-to-many;

dimension-to-dimension analysis;

dan beberapa security scenarios.

Namun Microsoft secara umum merekomendasikan agar penggunaan bidirectional relationship diminimalkan karena dapat berdampak pada query performance dan menghasilkan pengalaman yang membingungkan bagi pengguna report.

Jika hanya sebuah measure tertentu yang membutuhkan reverse filter propagation, CROSSFILTER sering menjadi pendekatan yang lebih terkendali dibanding mengubah physical relationship menjadi Both untuk seluruh model.

Prinsip terpenting yang dapat diingat adalah:

Jangan memilih Both karena Anda ingin filter bekerja ke mana-mana. Pilih arah filter berdasarkan ke mana filter memang seharusnya bergerak menurut business model.

Jika model bisnis hanya membutuhkan:

Product memfilter Sales;

Customer memfilter Sales;

Date memfilter Sales;

Store memfilter Sales,

maka Single sudah melakukan tugasnya dengan sempurna.

Jangan menambahkan kompleksitas yang tidak diperlukan.

Jika suatu hari muncul requirement: