One-to-One Relationship di Power BI: Panduan Lengkap dari Konsep hingga Best Practice

Relationship merupakan salah satu fondasi paling penting dalam data modeling Power BI. Banyak pengguna Power BI memulai proses pembuatan dashboard dengan mengimpor beberapa tabel, menghubungkannya berdasarkan kolom yang terlihat sama, kemudian langsung membuat visualisasi.

Pendekatan tersebut memang dapat menghasilkan dashboard yang terlihat bekerja. Namun, relationship yang secara teknis berhasil dibuat belum tentu menghasilkan model data yang baik.

Kesalahan dalam menentukan relationship dapat menyebabkan filter tidak bekerja seperti yang diharapkan, nilai total menjadi sulit dijelaskan, munculnya BLANK pada visual, hilangnya data tertentu, DAX menjadi semakin kompleks, hingga model Power BI menjadi sulit dikembangkan ketika jumlah tabel bertambah.

Salah satu relationship yang paling menarik untuk dipahami adalah One-to-One Relationship atau hubungan satu-ke-satu (1:1).

Relationship ini secara teknis terlihat sangat sederhana:

Table A 1 ↔ 1 Table B

Namun justru karena terlihat sederhana, relationship ini cukup sering disalahpahami.

Pertanyaan pentingnya bukan hanya:

Bagaimana cara membuat One-to-One Relationship di Power BI?

Pertanyaan yang jauh lebih penting adalah:

Apakah dua tabel tersebut memang seharusnya dihubungkan menggunakan relationship 1:1?

Dokumentasi Microsoft menjelaskan bahwa one-to-one relationship dapat dibuat ketika kedua tabel memiliki kolom yang berisi nilai umum dan nilai tersebut unik di masing-masing tabel. Microsoft juga menjelaskan bahwa terdapat dua skenario utama yang melibatkan relationship semacam ini, yaitu degenerate dimension dan kondisi ketika data sebuah entitas bisnis tersebar di beberapa tabel.

Artikel ini akan membahas konsep tersebut secara mendalam, mulai dari cardinality, uniqueness, grain, filter propagation, star schema, Power Query Merge, regular relationship, limited relationship, contoh kasus bisnis, DAX, troubleshooting, hingga decision framework untuk menentukan apakah relationship 1:1 memang merupakan pilihan yang tepat.

Apa Itu Relationship di Power BI?

Sebelum membahas one-to-one relationship, kita perlu memahami terlebih dahulu apa fungsi relationship di Power BI.

Relationship menghubungkan tabel-tabel di dalam semantic model sehingga filter yang diterapkan pada satu tabel dapat memengaruhi tabel lain yang berhubungan dengannya.

Misalnya kita memiliki tabel:

DimProduct

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

Kemudian terdapat tabel transaksi:

FactSales

TransactionID	ProductID	Quantity	Sales
T001	P001	10	500000
T002	P001	5	250000
T003	P002	7	280000
T004	P003	6	360000

ProductID pada DimProduct hanya muncul satu kali untuk setiap produk, sementara ProductID yang sama dapat muncul berkali-kali pada FactSales.

Relationship-nya adalah:

DimProduct 1 → * FactSales

Ketika pengguna memilih Category = Hair Care, Power BI dapat meneruskan filter dari DimProduct menuju FactSales dan menghitung hanya transaksi dari produk yang termasuk Hair Care.

Relationship bukan sekadar garis yang menghubungkan dua tabel pada Model View. Relationship menentukan bagaimana filter context bergerak di dalam semantic model.

Apa Itu Cardinality di Power BI?

Cardinality menjelaskan karakteristik hubungan antara nilai pada kolom yang digunakan sebagai relationship.

Power BI mendukung beberapa cardinality utama:

Cardinality	Notasi	Karakteristik
One-to-Many	1:*	Satu sisi unik, sisi lainnya dapat memiliki duplicate
Many-to-One	*:1	Kebalikan dari One-to-Many
One-to-One	1:1	Kedua sisi memiliki nilai unik
Many-to-Many	:	Kedua sisi dapat memiliki duplicate

Microsoft menjelaskan bahwa many-to-one atau kebalikannya, one-to-many, merupakan tipe relationship yang paling umum. Pada relationship 1:1, setiap nilai pada satu tabel hanya memiliki satu instance, dan tabel terkait juga hanya memiliki satu instance dari nilai tersebut.

Apa Itu One-to-One Relationship di Power BI?

One-to-One Relationship adalah relationship ketika kolom key pada kedua tabel sama-sama mempunyai nilai unik.

Misalnya kita mempunyai tabel Employee.

EmployeeID	EmployeeName	Department
E001	Andi	Sales
E002	Budi	Finance
E003	Citra	Marketing

Kemudian terdapat EmployeeProfile.

EmployeeID	Education	City
E001	S1	Jakarta
E002	S2	Bandung
E003	S1	Surabaya

EmployeeID pada Employee:

E001, E002, E003

semuanya unik.

EmployeeID pada EmployeeProfile juga:

E001, E002, E003

dan semuanya unik.

Karena itu relationship dapat berbentuk:

Employee[EmployeeID] 1 ↔ 1 EmployeeProfile[EmployeeID]

Inilah relationship satu-ke-satu.

Syarat Utama Relationship 1:1: Key Harus Unik di Kedua Tabel

Konsep uniqueness merupakan hal yang sangat penting.

Perhatikan contoh berikut.

Table A

CustomerID
C001
C002
C003

Table B

CustomerID
C001
C002
C003

Kedua sisi unik.

Maka relationship dapat menjadi:

Table A 1 ↔ 1 Table B

Sekarang ubah Table B menjadi:

CustomerID
C001
C001
C002
C003

C001 muncul dua kali.

Table B tidak lagi mempunyai key yang unik.

Relationship tersebut karena itu bukan 1:1.

Apabila Table A tetap unik, relationship lebih mungkin berbentuk:

Table A 1 → * Table B

Uniqueness Tidak Sama dengan Business Correctness

Ini adalah bagian yang sering terlewat.

Power BI dapat melihat sebuah kolom sebagai unik secara teknis. Namun uniqueness belum tentu berarti bahwa desain tabel sudah benar secara bisnis.

Misalnya terdapat tabel Customer:

CustomerCode	CustomerName
C001	ABC Store
C002	XYZ Store

dan CustomerAddress:

CustomerCode	Address
C001	Jakarta
C002	Bandung

Relationship 1:1 memang valid.

Tetapi kita tetap perlu bertanya:

Apakah Customer dan CustomerAddress sebenarnya merupakan dua entitas bisnis yang berbeda?

Jika jawabannya tidak, mungkin struktur yang lebih sederhana adalah:

CustomerCode	CustomerName	Address
C001	ABC Store	Jakarta
C002	XYZ Store	Bandung

Dengan kata lain:

key unik adalah syarat teknis untuk 1:1, tetapi bukan alasan desain yang cukup untuk menggunakan 1:1.

Konsep Grain: Dasar untuk Menentukan Cardinality yang Benar

Sebelum membuat relationship apa pun, biasakan mengajukan pertanyaan berikut:

Satu baris pada tabel ini mewakili apa?

Jawaban pertanyaan tersebut menentukan grain atau granularity tabel.

Misalnya:

DimProduct:

Satu baris = satu SKU.

FactSales:

Satu baris = satu invoice line.

Karena satu SKU dapat muncul pada banyak invoice line:

DimProduct 1 → * FactSales

Sekarang misalkan terdapat:

OrderReference:

Satu baris = satu OrderLineID.

dan SalesDetail:

Satu baris = satu OrderLineID.

Jika kedua tabel memiliki tepat satu row untuk setiap OrderLineID, 1:1 mungkin masuk akal.

Dengan demikian, cardinality seharusnya merupakan konsekuensi dari grain, bukan sesuatu yang dipilih secara sembarangan melalui dropdown Power BI.

One-to-One Relationship Selalu Menggunakan Cross Filter Direction Both

Ini merupakan karakteristik sangat penting dari relationship 1:1.

Microsoft menjelaskan bahwa untuk cardinality one-to-one, cross-filter direction selalu bekerja dari kedua tabel atau Both.

Dengan kata lain:

Table A ↔ Table B

Filter dari Table A dapat memengaruhi Table B.

Filter dari Table B juga dapat memengaruhi Table A.

Misalnya:

Product

SKU	Product
CL-01	T-Shirt
CL-02	Jeans
AC-01	Cap

dan:

ProductCategory

SKU	Category
CL-01	Clothing
CL-02	Clothing
AC-01	Accessories

Ketika Category = Clothing dipilih, filter dapat bergerak dari ProductCategory ke Product.

Begitu pula filter dari Product dapat memengaruhi ProductCategory.

Mengapa Bidirectional Filtering Perlu Dipahami?

Secara umum, Microsoft merekomendasikan agar penggunaan relationship bidirectional diminimalkan karena dapat meningkatkan kompleksitas filter propagation, memengaruhi performa query, dan berpotensi menghasilkan pengalaman yang membingungkan bagi pengguna report. Namun relationship 1:1 merupakan salah satu kasus khusus karena memang harus bersifat bidirectional.

Artinya, pada relationship 1:1 Anda tidak menyelesaikan persoalan dengan berkata:

Saya ubah saja menjadi Single Direction.

Yang perlu dievaluasi justru:

Apakah relationship 1:1 itu sendiri memang perlu ada?

Mengapa One-to-One Relationship Tidak Terlalu Umum?

Bayangkan kita mempunyai tabel Product.

SKU	Product	Color
P001	Shampoo A	White
P002	Shampoo B	Blue
P003	Soap A	Green

Kemudian ProductMarketing:

SKU	Brand	Category
P001	Brand A	Shampoo
P002	Brand B	Shampoo
P003	Brand A	Soap

Karena SKU unik pada kedua tabel, relationship berikut valid:

Product 1 ↔ 1 ProductMarketing

Namun secara konseptual Product dan ProductMarketing sama-sama berisi atribut yang menjelaskan satu entitas:

Product.

Mengapa tidak membuat satu DimProduct saja?

SKU	Product	Color	Brand	Category
P001	Shampoo A	White	Brand A	Shampoo
P002	Shampoo B	Blue	Brand B	Shampoo
P003	Soap A	Green	Brand A	Soap

Microsoft secara eksplisit merekomendasikan agar ketika row data satu entitas tersebar di beberapa model table dalam source group yang sama, data tersebut dikonsolidasikan menjadi satu model table bila memungkinkan.

Mengapa Konsolidasi Sering Lebih Baik?

Memecah satu business entity menjadi banyak tabel 1:1 dapat memberikan beberapa konsekuensi.

Pertama, Data pane menjadi lebih ramai.

Bayangkan report author melihat:

DimProduct

DimProductCategory

DimProductMarketing

DimProductAttribute

DimProductPackaging

Padahal semuanya mendeskripsikan produk.

Report author kemudian harus bertanya:

Product Name ada di tabel yang mana?

Brand harus diambil dari mana?

Category ada pada tabel apa?

Kedua, atribut terkait menjadi tersebar di beberapa tempat.

Ketiga, hierarchy lebih sulit dibuat.

Keempat, unmatched rows dapat menghasilkan BLANK atau perilaku lain yang tidak diharapkan.

Microsoft menyebut keempat konsekuensi tersebut sebagai alasan untuk menghindari pemisahan row data satu entitas ke beberapa tabel 1:1 jika konsolidasi memungkinkan.

Hubungan dengan Star Schema

Untuk memahami mengapa 1:1 bukan relationship yang dominan pada model Power BI, kita perlu memahami star schema.

Dalam star schema, tabel biasanya dibagi menjadi dua kategori utama:

Dimension table digunakan untuk filtering dan grouping.

Fact table digunakan untuk menyimpan observation, event, measurement, atau transaksi yang dapat diringkas.

Microsoft menjelaskan bahwa pada relationship one-to-many yang umum dalam star schema, sisi “one” berperan sebagai dimension dan sisi “many” berperan sebagai fact.

Contohnya:

DimDate 1 → * FactSales

DimProduct 1 → * FactSales

DimCustomer 1 → * FactSales

DimStore 1 → * FactSales

DimSalesperson 1 → * FactSales

Secara konseptual modelnya seperti bintang.

FactSales berada di tengah.

Dimension mengelilinginya.

Inilah pola yang sangat umum dalam semantic model Power BI.

Apakah Banyak Relationship 1:1 Menandakan Model yang Salah?

Tidak selalu.

Tetapi jika hampir seluruh model Anda terdiri dari:

Table A 1↔1 Table B

Table B 1↔1 Table C

Table C 1↔1 Table D

Table D 1↔1 Table E

maka model tersebut layak diperiksa ulang.

Bisa jadi struktur database operasional sedang dipindahkan mentah-mentah ke Power BI tanpa melakukan dimensional modeling.

Struktur database transaksi dan semantic model mempunyai tujuan berbeda.

Database transaksional cenderung dirancang untuk:

insert, update, consistency, transactional processing, dan pengurangan redundansi.

Semantic model analitik dirancang untuk:

filtering, grouping, aggregation, analytical querying, usability, dan business reporting.

Karena itu model Power BI tidak harus meniru struktur database sumber secara persis.

Relationship Bukan Merge

Kesalahan konseptual lain yang umum adalah menganggap relationship sama dengan Merge Query.

Keduanya berbeda.

Relationship

Misalnya:

Customer:

CustomerID | CustomerName

dan:

CustomerProfile:

CustomerID | City

Jika dibuat relationship, kedua tabel tetap berada dalam model sebagai dua tabel berbeda.

Power BI hanya membangun hubungan logis di antara keduanya.

Merge Query

Jika menggunakan Merge di Power Query, kedua sumber dapat dikonsolidasikan sehingga hasil akhirnya menjadi:

CustomerID | CustomerName | City

dan dimuat menjadi satu dimension:

DimCustomer

Kapan Sebaiknya Menggunakan Merge Query?

Pertimbangkan Merge Query ketika:

kedua tabel menggambarkan business entity yang sama;

grain kedua tabel sama;

key pada kedua tabel dapat dicocokkan;

atribut secara logis lebih mudah digunakan jika berada pada satu dimension;

dan kedua sumber dapat dikonsolidasikan pada tahap data preparation.

Microsoft secara khusus menyarankan konsolidasi untuk relationship 1:1 dalam source group yang sama saat row data satu entitas tersebar di beberapa tabel model. Salah satu pendekatan yang direkomendasikan adalah menggunakan Merge Queries di Power Query.

Mengapa Left Outer Join Sering Tepat?

Misalnya ProductMaster berisi 10.000 SKU.

ProductMarketing hanya berisi 9.700 SKU.

Jika ProductMaster dianggap sebagai daftar produk utama yang lengkap, kita biasanya ingin mempertahankan seluruh 10.000 SKU.

Maka pendekatan yang masuk akal adalah:

ProductMaster LEFT OUTER JOIN ProductMarketing

Dengan cara ini seluruh baris ProductMaster tetap dipertahankan, sedangkan atribut ProductMarketing ditambahkan ketika pasangan SKU tersedia.

Microsoft juga menyarankan mempertimbangkan kelengkapan masing-masing query dan menggunakan left outer join ketika query pertama merupakan master lengkap yang barisnya perlu dipertahankan.

Apa yang Terjadi pada SKU yang Tidak Memiliki Pasangan?

Misalnya:

ProductMaster:

SKU	Product
P001	Shampoo
P002	Soap
P003	Toothpaste

ProductMarketing:

SKU	Category
P001	Hair Care
P002	Personal Care

P003 tidak mempunyai pasangan.

Setelah merge:

SKU	Product	Category
P001	Shampoo	Hair Care
P002	Soap	Personal Care
P003	Toothpaste	null

Nilai null tersebut kemudian dapat diganti dengan token yang mudah dimengerti pengguna.

Misalnya:

Not Specified

atau:

Tidak Ditentukan

Microsoft memberikan rekomendasi serupa untuk mencegah BLANK yang membingungkan report author ketika melakukan filtering atau grouping.

Disable Load Setelah Merge

Setelah query tambahan berhasil digabungkan ke query utama, tidak selalu perlu memuat kedua query tersebut sebagai tabel model.

Misalnya:

ProductMaster menjadi DimProduct final.

ProductMarketing hanya digunakan sebagai staging query.

Setelah atribut ProductMarketing sudah dimasukkan ke DimProduct, query ProductMarketing dapat dipertimbangkan untuk dinonaktifkan dari load jika memang tidak lagi diperlukan sebagai model table.

Tujuannya:

mengurangi tabel yang tidak perlu;

mengurangi kekacauan Data pane;

dan membuat semantic model lebih mudah dipahami.

Microsoft memasukkan langkah menonaktifkan query load sebagai bagian dari metodologi konsolidasi 1:1 tersebut.

Bagaimana Jika Saya Tetap Ingin Memisahkan Field?

Ada pengguna yang sengaja memisahkan tabel karena ingin Data pane terlihat lebih terorganisasi.

Misalnya mereka ingin:

Product Core;

Product Marketing;

Product Logistics.

Namun jika semua atribut sebenarnya milik Product, Anda tidak selalu membutuhkan tiga tabel.

Alternatif yang jauh lebih bersih adalah menggunakan Display Folder.

Misalnya satu DimProduct berisi:

SKU

Product

Brand

Keuntungan Konsolidasi terhadap Hierarchy

Misalnya Anda ingin hierarchy:

Category → Subcategory → Product

Jika Category, Subcategory, dan Product berada dalam satu DimProduct, hierarchy tersebut mudah dibuat.

Namun jika masing-masing atribut berada pada tabel berbeda, penyusunan hierarchy menjadi lebih terbatas karena level hierarchy harus berasal dari tabel yang sama.

Microsoft mencantumkan keterbatasan hierarchy sebagai salah satu alasan mengapa pemecahan satu entitas ke beberapa tabel 1:1 sering tidak ideal.

Skenario Valid 1: Degenerate Dimension

Setelah membahas alasan menghindari 1:1, kita perlu melihat bahwa relationship ini tetap mempunyai skenario penggunaan yang valid.

Salah satunya adalah degenerate dimension.

Bayangkan FactSales mempunyai data:

OrderLineID	OrderNumber	OrderLineNumber	ProductID	Qty	Sales
1001001	SO1001	1	P001	5	500000
1001002	SO1001	2	P002	2	200000
1002001	SO1002	1	P003	3	450000

OrderNumber dan OrderLineNumber bukan measurement.

Mereka lebih dekat dengan atribut yang dapat digunakan untuk:

filtering;

grouping;

drill-through;

searching;

dan reporting detail.

Atribut tersebut dapat dipisahkan menjadi dimension:

OrderLineID	OrderNumber	OrderLineNumber
1001001	SO1001	1
1001002	SO1001	2
1002001	SO1002	1

Relationship dapat menjadi:

DimSalesOrder 1 ↔ 1 FactSales

Karena setiap OrderLineID hanya mempunyai satu row di masing-masing tabel.

Microsoft menjelaskan bahwa memisahkan kolom fact yang digunakan untuk filtering atau grouping ke tabel terpisah dapat membantu mengurangi storage, menyederhanakan model calculation, membantu query performance, dan memberikan pengalaman Data pane yang lebih intuitif bagi report author.

Apa Itu Degenerate Dimension?

Degenerate dimension secara sederhana adalah atribut dimensional yang secara alami terdapat pada fact table tetapi tidak selalu mempunyai dimension table terpisah pada source system.

Contoh umum:

Invoice Number

Order Number

Ticket Number

Transaction Reference

Purchase Order Number

Atribut seperti ini sering dibutuhkan untuk pencarian, grouping, drill-through, atau audit transaksi meskipun tidak memiliki kumpulan atribut dimensional besar seperti Product atau Customer.

Skenario Valid 2: Data Satu Entitas Berasal dari Beberapa Sistem

Skenario berikutnya terjadi ketika informasi mengenai satu business entity berada pada dua atau lebih source system.

Misalnya ERP mempunyai ProductMaster:

SKU	Product	Size	UOM
P001	Shampoo A	200 ml	PCS
P002	Soap A	100 gr	PCS

Sistem Marketing mempunyai:

SKU	Brand	Category	Segment
P001	Brand A	Hair Care	Premium
P002	Brand B	Personal Care	Mass

Keduanya memiliki satu baris per SKU.

Secara teknis relationship:

ProductMaster 1 ↔ 1 ProductMarketing

dapat digunakan.

Tetapi keputusan akhirnya tetap bergantung pada apakah kedua sumber tersebut dapat dikonsolidasikan sebelum atau ketika dimuat ke semantic model.

Intra Source Group One-to-One Relationship

Microsoft membedakan relationship berdasarkan source group.

Ketika dua tabel 1:1 berada dalam source group yang sama, relationship tersebut dapat dievaluasi sebagai regular relationship.

Untuk kasus ketika row data satu entitas tersebar di kedua tabel, Microsoft merekomendasikan konsolidasi menjadi satu model table apabila memungkinkan.

Pola sederhananya:

Product Master

Product Category

↓

Power Query Merge

↓

DimProduct

Cross Source Group One-to-One Relationship

Skenario menjadi lebih menarik ketika dua tabel berasal dari source group berbeda.

Misalnya salah satu tabel berada pada source tertentu dan tabel lain berasal dari source group berbeda dalam composite model.

Microsoft menjelaskan bahwa one-to-one cross-source-group relationship dievaluasi sebagai limited relationship.

Ini bukan sekadar istilah teknis.

Konsekuensinya dapat terlihat langsung pada hasil query.

Apa Itu Limited Relationship?

Pada limited relationship, Power BI tidak mempunyai kemampuan evaluasi relationship yang sama dengan regular relationship.

Salah satu konsekuensi yang penting pada skenario cross-source 1:1 adalah unmatched row dapat dieliminasi dari hasil query ketika field dari kedua tabel digunakan bersama.

Misalnya Table A:

SKU	Product
P001	Shampoo
P002	Soap
P003	Toothpaste

Table B:

SKU	Category
P001	Hair Care
P003	Oral Care

P002 tidak mempunyai pasangan.

Pada skenario cross-source limited relationship, row tersebut dapat tidak muncul ketika visual menggabungkan field dari kedua tabel.

Microsoft memberikan contoh serupa dengan SKU CL-02 yang tidak memiliki row pasangan pada Product Category. Pada cross-source 1:1, SKU tersebut hilang dari visual yang menggunakan field kedua tabel.

Regular Relationship vs Limited Relationship

Aspek	Regular Relationship	Limited Relationship
Evaluasi	Regular	Terbatas
Source	Umumnya intra source group	Dapat terjadi cross source group
Unmatched rows	Dapat muncul sebagai BLANK pada skenario tertentu	Dapat dieliminasi dari query result
Data integrity	Tetap penting	Sangat penting

Karena itu ketika bekerja dengan composite model, jangan hanya melihat simbol relationship pada Model View.

Pahami juga bagaimana relationship tersebut dievaluasi.

Masalah Missing Row pada Relationship 1:1

Kesalahpahaman yang umum adalah menganggap one-to-one berarti setiap baris harus mempunyai pasangan sempurna.

Secara praktis, dua kolom dapat tetap unik tetapi tidak mempunyai set nilai yang identik.

Misalnya Product:

SKU	Product
P001	Shampoo
P002	Soap
P003	Toothpaste

ProductCategory:

SKU	Category
P001	Hair Care
P002	Personal Care

P003 tidak memiliki pasangan.

Pada regular 1:1, visual dapat menghasilkan Category = BLANK untuk P003.

Microsoft memperlihatkan pola tersebut pada dokumentasi resminya.

Mengapa BLANK Tidak Boleh Langsung Dianggap Masalah DAX?

Ketika melihat BLANK pada report, banyak developer langsung mencoba membuat DAX:

COALESCE()

atau

IF(ISBLANK(...))

Padahal masalahnya bisa berada pada relationship atau source data.

BLANK dapat menunjukkan:

missing dimension member;

key tidak mempunyai pasangan;

data belum lengkap;

relationship salah;

grain tidak cocok;

atau data integrity issue.

Karena itu jangan menggunakan DAX untuk menutupi masalah data modeling sebelum penyebabnya diketahui.

Prinsip Penting: Jangan Memperbaiki Model Buruk dengan DAX Kompleks

Salah satu prinsip yang sangat berguna dalam Power BI adalah:

Model data yang sederhana biasanya menghasilkan DAX yang lebih sederhana.

Sebaliknya:

Model yang ambigu dan terlalu kompleks sering memaksa developer membuat DAX yang semakin kompleks.

Sebelum membuat measure panjang untuk memaksa filter bergerak sesuai keinginan, evaluasi:

grain;

cardinality;

dimension;

fact;

relationship direction;

dan model architecture.

Cara Membuat One-to-One Relationship di Power BI

Untuk membuat relationship 1:1, pertama pastikan kedua tabel sudah tersedia di semantic model.

Kemudian identifikasi kolom key.

Misalnya:

Employee[EmployeeID]

dan:

EmployeeProfile[EmployeeID]

Pastikan kedua key mempunyai data type yang kompatibel.

Kemudian periksa uniqueness pada kedua sisi.

Relationship dapat dibuat melalui Model View atau Manage Relationships.

Pilih kedua tabel dan kedua key yang akan dihubungkan.

Jika key kedua sisi unik, cardinality dapat ditetapkan sebagai:

One to one (1:1)

Cross filter direction untuk relationship tersebut adalah:

Both

Microsoft mendokumentasikan bahwa 1:1 hanya memiliki cross-filter option Both.

Cara Mengecek Apakah Key Benar-Benar Unik

Anda dapat menggunakan DAX sederhana.

Total Rows =
COUNTROWS(Employee)

Kemudian:

Distinct Employee ID =
DISTINCTCOUNT(Employee[EmployeeID])

Jika:

Total Rows = 10.000

dan:

Distinct Employee ID = 10.000

maka secara sederhana tidak terdapat duplicate nonblank yang mengurangi distinct count.

Jika:

Total Rows = 10.000

sedangkan:

Distinct Employee ID = 9.850

maka terdapat nilai EmployeeID yang berulang.

Pengecekan Duplicate melalui Power Query

Pengecekan juga dapat dilakukan di Power Query.

Anda dapat menggunakan:

Column Profile;

Column Distribution;

Keep Duplicates;

Group By;

atau kombinasi transformasi lainnya.

Namun jangan langsung memilih Remove Duplicates hanya karena ingin memaksa key menjadi unik.

Duplicate dapat berarti:

kesalahan data;

atau justru transaksi yang memang valid.

Contohnya ProductID pada FactSales memang seharusnya berulang.

Menghapus duplicate dari FactSales hanya agar ProductID menjadi unik akan menghancurkan data transaksi.

One-to-One vs One-to-Many

Aspek	One-to-One	One-to-Many
Cardinality	1:1	1:*
Sisi pertama	Unique	Unique
Sisi kedua	Unique	Dapat berulang
Cross filter	Both	Umumnya dari dimension ke fact
Penggunaan	Lebih khusus	Sangat umum
Star schema	Bukan pola utama	Pola utama

One-to-One vs Many-to-Many

One-to-one membutuhkan key unik pada kedua sisi.

Many-to-many memungkinkan duplicate pada kedua sisi.

Contoh:

Salesperson dapat menangani beberapa Region.

Satu Region dapat ditangani beberapa Salesperson.

Hubungan bisnis tersebut merupakan many-to-many.

Dalam model dimensional, bridge table sering menjadi pola yang lebih tepat untuk menghubungkan dua dimension dalam skenario seperti ini. Microsoft juga merekomendasikan penggunaan bridging table untuk desain many-to-many antar dimension.

Jangan Menghapus Duplicate untuk Menghindari Many-to-Many

Misalnya:

Customer A membeli Product X tiga kali.

Jika Anda menghapus dua transaksi agar Customer A hanya muncul satu kali, Anda memang dapat membuat suatu kolom terlihat unik.

Tetapi model Anda menjadi salah secara bisnis.

Relationship harus mengikuti realitas data, bukan sebaliknya.

Jika bisnis memang many-to-many, model-lah relationship tersebut secara benar.

One-to-One antara Dua Fact Table

Microsoft menjelaskan bahwa menghubungkan dua fact table menggunakan one-to-one relationship merupakan skenario yang tidak umum. Agar relationship semacam itu masuk akal, kedua fact table perlu mempunyai dimension dan granularity yang sama serta masing-masing memerlukan kolom unik untuk membangun relationship.

Ini merupakan syarat yang cukup kuat.

Karena itu jika Anda menemukan:

FactSales 1 ↔ 1 FactSomething

periksa kembali grain kedua fact table.

Contoh Kasus Bisnis FMCG

Bayangkan perusahaan FMCG memiliki data Product dari ERP.

ERP ProductMaster:

SKU

ProductName

PackSize

UOM

Status

Sementara tim Marketing mempunyai ProductMarketing:

SKU

Brand

Contoh Kasus HR

Misalnya terdapat EmployeeMaster dan EmployeeProfile.

EmployeeMaster:

EmployeeID

Name

Department

Position

EmployeeProfile:

EmployeeID

Education

City

JoinSource

Relationship 1:1 valid jika EmployeeID unik pada keduanya.

Tetapi jika semua atribut tersebut menggambarkan employee yang sama dan tidak ada alasan kuat untuk mempertahankannya terpisah, DimEmployee yang terkonsolidasi biasanya lebih mudah digunakan.

Contoh Kasus Customer

Misalnya:

CustomerMaster berasal dari ERP.

CustomerSegmentation berasal dari CRM.

Setiap CustomerID unik pada kedua tabel.

1:1 mungkin diperlukan jika kedua data berada dalam sistem yang tidak dapat dikonsolidasikan pada layer sebelumnya.

Namun jika Power Query mampu menggabungkannya secara aman, DimCustomer tunggal dapat memberikan pengalaman reporting yang lebih sederhana.

Model yang Secara Teknis Benar Belum Tentu Mudah Digunakan

Ini merupakan prinsip semantic modeling yang sering diabaikan.

Misalnya dua desain berikut sama-sama dapat menghasilkan angka penjualan yang benar.

Model A mempunyai 18 tabel dengan banyak relationship 1:1.

Model B mempunyai 7 tabel dengan dimension yang dikonsolidasikan dan relationship star schema yang jelas.

Dari perspektif report author, Model B biasanya jauh lebih intuitif.

Semantic model bukan hanya mesin perhitungan.

Semantic model merupakan interface antara data dan pengguna bisnis.

Lima Kriteria Model Power BI yang Baik

Model yang baik idealnya memenuhi lima aspek.

1. Accuracy

Angka harus benar.

2. Performance

Query dan refresh harus berjalan efisien.

3. Usability

Report author mudah menemukan field.

4. Maintainability

Model mudah dipelihara dan dikembangkan.

5. Scalability

Model tetap terkelola ketika kebutuhan bisnis bertambah.

Relationship 1:1 harus dievaluasi terhadap kelima aspek tersebut, bukan hanya berdasarkan fakta bahwa relationship dapat dibuat.

Decision Framework: Haruskah Saya Menggunakan Relationship 1:1?

Gunakan alur berpikir berikut.

Pertanyaan 1:

Apakah key pada kedua tabel benar-benar unik?

Jika tidak, relationship bukan 1:1.

Pertanyaan 2:

Apakah kedua tabel memiliki grain yang sama?

Jika tidak, evaluasi kembali cardinality.

Pertanyaan 3:

Apakah kedua tabel menggambarkan business entity yang sama?

Jika ya, pertimbangkan konsolidasi.

Pertanyaan 4:

Bisakah kedua tabel digabungkan melalui Power Query atau data source?

Jika ya, satu dimension mungkin lebih sederhana.

Pertanyaan 5:

Apakah terdapat alasan bisnis atau teknis yang kuat untuk mempertahankannya terpisah?

Jika ya, 1:1 mungkin tepat.

Pertanyaan 6:

Apakah relationship melintasi source group?

Jika ya, pahami limited relationship dan dampak unmatched rows.

Pertanyaan 7:

Apakah seluruh key mempunyai pasangan?

Jika tidak, tentukan bagaimana missing member akan ditangani.

Red Flags pada Relationship 1:1

Beberapa tanda berikut patut menjadi perhatian.

Model mempunyai terlalu banyak tabel 1:1.

Semua tabel 1:1 menggambarkan entity yang sama.

Field terkait sulit ditemukan.

Hierarchy tidak dapat dibuat dengan mudah.

Banyak BLANK muncul karena key tidak match.

DAX menjadi panjang hanya untuk mengatur filter.

Struktur semantic model terlihat persis seperti database OLTP.

Duplicate dihapus secara sembarangan agar cardinality berubah.

Developer tidak dapat menjelaskan grain setiap tabel.

Jika beberapa red flag tersebut muncul bersamaan, model layak direview.

Kesalahan Umum: Menganggap Auto Detect Selalu Menentukan Model Terbaik

Power BI dapat membantu mendeteksi relationship berdasarkan data.

Namun software tidak mengetahui keseluruhan business semantics Anda.

Power BI dapat mengetahui bahwa kolom A unik.

Power BI dapat mengetahui bahwa kolom B unik.

Power BI kemudian dapat mengizinkan relationship 1:1.

Tetapi Power BI tidak selalu mengetahui apakah kedua tabel seharusnya dikonsolidasikan secara konseptual.

Keputusan terakhir tetap merupakan tanggung jawab data modeler.

Kesalahan Umum: Memaksakan 1:1 dengan Remove Duplicates

Misalnya sebuah tabel mempunyai:

P001

P002

P003

Developer kemudian memilih Remove Duplicates supaya menjadi:

P001

P002

P003

dan setelah itu membuat relationship 1:1.

Ini sangat berbahaya jika row kedua P001 sebenarnya mewakili transaksi atau kondisi bisnis yang valid.

Jangan mengubah data hanya untuk memenuhi relationship yang Anda inginkan.

Tentukan relationship berdasarkan grain data yang sebenarnya.

Kesalahan Umum: Tidak Memeriksa Data Type

Kolom relationship sebaiknya memiliki tipe data yang kompatibel.

Contoh buruk:

Table A ProductID = Whole Number

Table B ProductID = Text

Walaupun nilai secara visual terlihat sama, perbedaan data type dapat menyebabkan masalah ketika membuat atau menggunakan relationship.

Kesalahan Umum: Tidak Memeriksa Referential Integrity

Misalnya DimProduct mempunyai:

P001

P002

P003

Tabel lain hanya memiliki:

P001

P003

P002 tidak match.

Pertanyaan penting:

Apakah P002 memang tidak seharusnya mempunyai data?

Apakah source belum update?

Apakah ada whitespace?

Apakah case berbeda?

Apakah key berubah?

Apakah data tidak sinkron?

Data modeling yang baik memerlukan data quality discipline.

Kesalahan Umum: Menggunakan DAX untuk Menutupi Data Quality Issue

Jika Category BLANK karena Product tidak mempunyai pasangan, formula seperti berikut mungkin hanya menutupi gejala:

Category Display =
COALESCE(
    SELECTEDVALUE(ProductCategory[Category]),
    "Unknown"
)

Formula tersebut mungkin berguna pada presentation layer, tetapi tetap perlu diketahui mengapa relationship menghasilkan missing value.

Jika masalah berasal dari source data, perbaikannya sebaiknya dilakukan sedekat mungkin dengan sumber masalah.

DAX untuk Audit Uniqueness

Selain membandingkan jumlah row dan distinct key, Anda dapat membuat indikator sederhana.

Duplicate Count =
COUNTROWS(Employee)
    - DISTINCTCOUNT(Employee[EmployeeID])

Jika hasilnya lebih besar dari nol, terdapat indikasi duplicate pada key.

Untuk audit yang lebih detail, pengecekan sebaiknya dilakukan pada data preparation layer atau source system sehingga duplicate record dapat diidentifikasi secara langsung.

DAX dan Relationship

DAX sangat bergantung pada filter context.

Relationship menentukan jalur filter context antar tabel.

Karena itu formula yang terlihat sederhana dapat memberikan hasil berbeda jika model relationship berbeda.

Misalnya:

Total Sales =
SUM(FactSales[SalesAmount])

Measure tersebut sangat sederhana.

Tetapi kemampuannya merespons:

Product;

Category;

Customer;

Date;

Region;

dan Salesperson

bergantung pada relationship model.

Ini adalah alasan mengapa data modeling merupakan keterampilan fundamental bagi developer Power BI.

Relationship Menentukan Filter Context

Misalnya DimProduct memfilter FactSales.

Ketika pengguna memilih:

Category = Hair Care

filter context bergerak:

DimProduct → FactSales.

Measure Total Sales kemudian dihitung hanya dari row FactSales yang berhubungan dengan Hair Care.

Pada relationship 1:1, filter dapat bergerak dari kedua tabel.

Karena itu developer harus memahami keseluruhan filter path dalam model.

One-to-One dan Ambiguity

Bidirectional filtering dapat menambah kompleksitas ketika sebuah model memiliki beberapa jalur relationship yang memungkinkan filter mencapai tabel yang sama melalui route berbeda.

Power BI memiliki mekanisme untuk mencegah konfigurasi relationship tertentu ketika menghasilkan ambiguity, tetapi data modeler tetap harus merancang relationship topology secara hati-hati.

Semakin banyak relationship dua arah dalam model, semakin sulit seseorang memahami bagaimana filter bergerak.

Kenapa Model Sederhana Lebih Bernilai?

Dalam proyek nyata, semantic model hampir tidak pernah digunakan hanya oleh pembuat pertama.

Model dapat digunakan oleh:

report developer lain;

business analyst;

finance;

sales;

marketing;

management;

atau developer yang baru bergabung beberapa bulan kemudian.

Model yang memerlukan penjelasan panjang hanya untuk menemukan Product Category kemungkinan terlalu kompleks.

Kapan One-to-One Relationship Layak Dipertahankan?

Relationship 1:1 layak dipertimbangkan ketika pemisahan tabel mempunyai alasan yang nyata.

Contohnya:

degenerate dimension yang sengaja diturunkan dari fact;

business entity berasal dari source group berbeda;

arsitektur composite model membuat konsolidasi tidak praktis;

security atau technical requirement tertentu memerlukan pemisahan;

atau terdapat kebutuhan semantic modeling spesifik yang memberikan manfaat lebih besar dibandingkan konsolidasi.

Dengan kata lain:

Gunakan 1:1 karena desain membutuhkan 1:1, bukan hanya karena kedua key kebetulan unik.

Kapan Sebaiknya Menghindari One-to-One Relationship?

Pertimbangkan menghindarinya jika:

dua tabel hanyalah potongan atribut dari dimension yang sama;

Merge Query dapat menyelesaikan kebutuhan dengan lebih sederhana;

pemisahan hanya dilakukan karena source database juga terpisah;

report author kesulitan menemukan field;

hierarchy menjadi sulit dibuat;

atau relationship menciptakan kompleksitas tanpa memberikan manfaat bisnis yang jelas.

Best Practice Model Product

Daripada:

Product Core 1↔1 Product Category

Product Category 1↔1 Product Marketing

Product Marketing 1↔1 Product Packaging

pertimbangkan:

DimProduct

dengan atribut:

ProductKey

SKU

ProductName

Contoh Star Schema yang Lebih Bersih

Misalnya model sales:

DimDate

DimProduct

DimCustomer

DimSalesperson

DimRegion

mengelilingi:

FactSales

Relationship:

DimDate 1 → * FactSales

DimProduct 1 → * FactSales

DimCustomer 1 → * FactSales

DimSalesperson 1 → * FactSales

DimRegion 1 → * FactSales

Struktur seperti ini mudah dijelaskan, mudah digunakan, dan konsisten dengan prinsip star schema. Microsoft menempatkan dimension sebagai tabel filtering/grouping dan fact sebagai tabel summarization dalam desain star schema Power BI.

Troubleshooting: Power BI Tidak Mengizinkan 1:1

Jika Power BI tidak mengizinkan relationship 1:1, periksa beberapa hal.

Duplicate key

Kemungkinan ada nilai yang muncul lebih dari satu kali.

Blank key

Periksa keberadaan blank/null pada key dan dampaknya terhadap uniqueness.

Data type berbeda

Pastikan kedua kolom mempunyai tipe yang kompatibel.

Transformation menghasilkan duplicate

Merge, append, expand, atau transformasi lain dapat mengubah grain tabel.

Asumsi grain salah

Tabel yang Anda kira one row per customer mungkin sebenarnya one row per customer per period.

Contoh Grain yang Sering Disalahpahami

Misalnya sebuah tabel CustomerTarget mempunyai:

CustomerID

Month

Target

Developer menganggap CustomerID harus unik.

Padahal grain tabel adalah:

one row per customer per month.

CustomerID tentu berulang.

Jika hanya melihat nama kolom tanpa memahami grain, relationship dapat dirancang salah.

Composite Key dan Grain

Pada contoh CustomerTarget tadi, keunikan mungkin bukan CustomerID saja.

Keunikannya adalah kombinasi:

CustomerID + Month.

Konsep ini penting karena relationship harus merepresentasikan grain yang sebenarnya.

Pada beberapa desain, surrogate key atau composite business key dapat digunakan untuk mewakili grain tersebut dengan lebih jelas.

One-to-One Relationship dan Surrogate Key

Surrogate key merupakan key buatan yang digunakan untuk mengidentifikasi row secara unik.

Misalnya OrderNumber dan OrderLineNumber dapat dikombinasikan menjadi OrderLineID.

Contoh:

Order 1001, Line 1 → 1001001

Order 1001, Line 2 → 1001002

Order 1002, Line 1 → 1002001

Microsoft menggunakan konsep surrogate key semacam ini ketika menjelaskan degenerate dimension untuk Sales Order.

Apakah One-to-One Relationship Lebih Cepat?

Tidak tepat untuk menyimpulkan bahwa relationship 1:1 selalu lebih cepat daripada 1:* atau sebaliknya hanya berdasarkan cardinality.

Performance model dipengaruhi banyak faktor:

jumlah row;

cardinality kolom;

storage mode;

filter direction;

DAX;

jumlah visual;

source system;

query folding;

dan desain semantic model secara keseluruhan.

Karena itu pilih relationship berdasarkan logical model yang benar terlebih dahulu, kemudian optimalkan berdasarkan measurement nyata.

Gunakan Performance Analyzer untuk Validasi

Jika Anda melakukan redesign model dari banyak tabel 1:1 menjadi dimension yang lebih terkonsolidasi, gunakan Performance Analyzer untuk membandingkan report sebelum dan sesudah perubahan.

Jangan mengandalkan asumsi.

Ukur:

visual query duration;

DAX query;

refresh;

dan pengalaman pengguna.

Dokumentasikan Grain Setiap Tabel

Salah satu praktik yang sangat saya sarankan dalam proyek Power BI profesional adalah mendokumentasikan grain.

Contoh:

Table	Grain
DimProduct	One row per SKU
DimCustomer	One row per Customer
FactSales	One row per Invoice Line
FactInventory	One row per SKU per Warehouse per Date
FactTarget	One row per Salesperson per Month

Dokumentasi sederhana tersebut mencegah banyak kesalahan relationship.

Checklist Audit One-to-One Relationship

Pertanyaan	Tujuan
Apakah kedua key unik?	Validasi syarat teknis 1:1
Apakah grain kedua tabel sama?	Validasi struktur bisnis
Apakah kedua tabel menggambarkan entity sama?	Menentukan potensi konsolidasi
Apakah tabel dapat di-Merge?	Menyederhanakan model
Apakah seluruh key mempunyai pasangan?	Menilai data integrity
Apakah terdapat BLANK?	Mendeteksi unmatched member
Apakah relationship cross-source?	Menilai limited relationship
Apakah Data pane menjadi rumit?	Menilai usability
Apakah hierarchy terhambat?	Menilai report-author experience
Apakah DAX terlalu kompleks?	Mendeteksi modeling problem

Prinsip Utama yang Perlu Diingat

Relationship yang bisa dibuat belum tentu relationship yang sebaiknya dibuat.

Power BI mungkin mengizinkan:

Table A 1 ↔ 1 Table B.

Namun data modeler tetap harus menentukan apakah kedua tabel memang perlu dipertahankan sebagai dua tabel.

Itulah perbedaan antara sekadar membuat model yang bekerja dan membuat semantic model yang baik.

FAQ: One-to-One Relationship Power BI

Apa itu One-to-One Relationship di Power BI?

One-to-One Relationship adalah hubungan antara dua tabel ketika key yang digunakan pada kedua sisi sama-sama unik. Dengan demikian satu row dari tabel pertama dapat berhubungan dengan maksimal satu row pada tabel kedua dan sebaliknya.

Apakah One-to-One Relationship harus menggunakan Both Direction?

Ya. Microsoft mendokumentasikan bahwa cross filter direction untuk relationship 1:1 adalah Both. Filter dapat bergerak melalui kedua tabel.

Apakah One-to-One Relationship direkomendasikan?

Relationship tersebut valid, tetapi tidak seharusnya digunakan sebagai default. Untuk kondisi ketika satu business entity tersebar pada beberapa tabel dalam source group yang sama, Microsoft menyarankan konsolidasi menjadi satu model table bila memungkinkan.

Apakah relationship 1:1 sama dengan Merge Query?

Tidak. Relationship mempertahankan dua tabel sebagai model table terpisah dan menghubungkannya secara logis. Merge Query menggabungkan data pada tahap Power Query sehingga atribut dapat dimuat menjadi satu tabel.

Kapan saya sebaiknya menggunakan Merge daripada 1:1?

Jika kedua tabel mempunyai grain yang sama, menggambarkan entity bisnis yang sama, dan dapat dikonsolidasikan secara aman, Merge sering menghasilkan semantic model yang lebih sederhana.

Apakah key harus unik pada kedua tabel?

Ya. Uniqueness pada kedua sisi merupakan karakteristik utama cardinality 1:1.

Mengapa relationship 1:1 menghasilkan BLANK?

Salah satu penyebabnya adalah key pada satu tabel tidak memiliki row pasangan pada tabel lainnya. Pada regular relationship, masalah data integrity seperti ini dapat muncul sebagai BLANK pada visual.

Apa yang terjadi pada 1:1 cross-source relationship?

Microsoft menjelaskan bahwa relationship 1:1 lintas source group dievaluasi sebagai limited relationship. Unmatched rows dapat dieliminasi dari query result ketika field kedua tabel digunakan bersama.

Apa hubungan one-to-one dengan star schema?

One-to-one bukan relationship utama dalam star schema. Pola yang paling umum adalah one-to-many, dengan dimension berada pada sisi one dan fact berada pada sisi many.

Apakah banyak relationship 1:1 berarti model saya salah?

Tidak otomatis. Namun hal tersebut merupakan alasan yang baik untuk melakukan review apakah beberapa tabel sebenarnya dapat dikonsolidasikan atau apakah struktur database operasional telah disalin terlalu langsung ke semantic model.

Bagaimana cara mengetahui key saya unik?

Bandingkan jumlah row dengan distinct count key, gunakan data profiling Power Query, Group By, atau audit duplicate pada source data.

Apakah saya boleh menggunakan Remove Duplicates agar relationship menjadi 1:1?

Hanya jika duplicate memang terbukti merupakan data yang tidak seharusnya ada. Jangan menghapus duplicate yang merepresentasikan transaksi atau observation yang valid hanya demi mendapatkan cardinality tertentu.

Apakah One-to-One Relationship memengaruhi DAX?

Ya. Relationship menentukan jalur filter propagation dan karena DAX sangat bergantung pada filter context, struktur relationship dapat memengaruhi bagaimana measure dievaluasi.

Kesimpulan

One-to-One Relationship di Power BI merupakan relationship ketika kolom key pada kedua tabel mempunyai nilai yang unik.

Secara visual hubungan tersebut terlihat sederhana:

1 ↔ 1

Namun secara data modeling, keputusan menggunakannya tidak selalu sederhana.

Relationship 1:1 selalu menggunakan cross-filter direction Both. Relationship ini dapat muncul dalam skenario seperti degenerate dimension atau ketika data sebuah business entity tersebar pada beberapa tabel atau source system.

Namun ketika dua tabel dalam source group yang sama sebenarnya hanya berisi atribut berbeda dari satu entitas bisnis yang sama, Microsoft merekomendasikan untuk mempertimbangkan konsolidasi menjadi satu model table. Pendekatan tersebut dapat mengurangi clutter pada Data pane, memudahkan report author menemukan field terkait, mendukung hierarchy dengan lebih baik, dan mengurangi masalah akibat unmatched rows.

Sementara itu, star schema tetap menjadi landasan penting dalam semantic modeling Power BI. Dalam desain tersebut, dimension table digunakan untuk filtering dan grouping sedangkan fact table digunakan untuk summarization, dengan one-to-many sebagai relationship yang paling umum.

Karena itu, setiap kali Anda melihat relationship:

Table A 1 ↔ 1 Table B

jangan berhenti pada pertanyaan:

Apakah Power BI mengizinkan relationship ini?

Tanyakan:

Apakah kedua tabel ini memang merupakan dua entity yang perlu tetap dipisahkan?

Jika jawabannya tidak, konsolidasi mungkin merupakan pendekatan yang lebih sederhana.

Jika jawabannya ya, pastikan Anda memahami uniqueness, grain, filter propagation, data integrity, regular versus limited relationship, serta konsekuensinya terhadap report.

Pada akhirnya, tujuan data modeling bukan membuat sebanyak mungkin relationship.

Tujuannya adalah menciptakan semantic model yang:

akurat, sederhana, mudah dipahami, efisien, scalable, dan menghasilkan analytical experience yang dapat dipercaya.

Dan itulah prinsip yang seharusnya menjadi dasar setiap keputusan relationship di Power BI.