Data Master dan Identitas
Juga tersedia dalam 28 bahasa
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Panduan belajar untuk bab 6 kursus Data Architect. Baca dulu enam modulnya, termasuk pembahasan Checkpoint 1; halaman ini membantu Anda memeriksa apa yang sudah melekat.
Tentang panduan belajar ini. Panduan ini disusun hanya dari konten kursus ini sendiri dan daftar tujuan yang tercantum dalam panduan ujian resmi Salesforce. Panduan ini tidak pernah didasarkan pada soal ujian yang sebenarnya, dan tidak mengklaim tahu apa yang keluar di ujian. Jika Anda sudah mengikuti ujiannya, mohon jangan kirimkan soal-soalnya kepada saya: perjanjian sertifikasi melarang membagikannya, dan menghafal jawaban memang cara yang salah untuk menjadi arsitek.
Bab ini memikul bagian Master Data Management dalam ujian (5%) dan tampilan tunggal pelanggan dari Salesforce Data Management. Bobot bagiannya kecil, tetapi gagasan-gagasannya (otoritas, pencocokan, survivorship) muncul di dalam banyak skenario lain. Angka-angka platform berubah, jadi periksa angka terkininya sebelum Anda mengandalkannya.
Untuk Ujian
Section titled “Untuk Ujian ”Centang satu per satu sambil berjalan. Setiap poin bertaut ke tempat ia diajarkan.
MDM-2: golden record dan sistem kebenaran
- Saya tahu bahwa otoritas ditetapkan per atribut, bukan per rekaman: satu akun bisa punya bidang yang dikelola di ERP dan bidang yang dikelola di Salesforce. (Kebenaran Dimiliki oleh Atribut)
- Saya menanyakan di mana setiap atribut dibuat, diedit, dan dirujuk, serta latensi perubahannya. (Dibuat, Diedit, Dirujuk, dan Seberapa Cepat?)
- Saya bisa membangun peta otoritas, dan saya tahu bahwa pemilik bisnis dan sistem otoritatif bukanlah hal yang sama. (Bangun Peta Otoritas)
- Saya tahu bahwa otoritas bisa berubah sepanjang siklus hidup (prospek di Salesforce menjadi pelanggan yang dikelola ERP), dan bahwa salinan bukanlah otoritas. (Otoritas Berubah Sepanjang Siklus Hidup, Salinan Bukanlah Otoritas)
MDM-1: teknik-teknik MDM
- Pengetahuan untuk ujian: Saya tahu empat gaya implementasi MDM, yaitu registri, konsolidasi, koeksistensi, dan terpusat: apa yang dipusatkan masing-masing dan apakah ia mengirim nilai kembali. (Keempatnya Berdampingan)
- Saya bisa membedakan empat gaya MDM: registri, konsolidasi, koeksistensi, dan terpusat, dan memilih yang paling ringan yang menyelesaikan masalahnya. (Keempatnya Berdampingan)
- Saya tahu bahwa model data kanonis mengharmonisasikan struktur, tetapi tidak memutuskan otoritas. (Model Bersama Bukanlah Kebenaran Bersama)
- Saya tahu urutannya: harmonisasi, lalu pencocokan, lalu konsolidasi. (Harmonisasi, lalu Pencocokan, lalu Konsolidasi)
- Saya tahu bahwa ambang mencerminkan toleransi terhadap kesalahan, dan pengayaan butuh asal-usul yang jelas. (Ambang, Tinjauan, dan Pengayaan)
- Pengetahuan untuk ujian: Saya memahami manajemen hierarki: Akun Induk (Parent Account) membangun hierarkinya (tampilan Lightning menampilkan hingga 2.000 akun, tanpa akun pribadi), hierarki sering dikelola oleh beberapa master, dan sebuah perusahaan bisa punya beberapa hierarki yang sah. (Hierarki Juga Data Master, Satu Hierarki, Beberapa Master)
MDM-3: memilih atribut pemenang
- Saya memisahkan pencocokan, penggabungan, dan survivorship. (Pencocokan, Penggabungan, dan Survivorship)
- Saya tahu aturan-aturan survivorship: paling baru, paling sering, prioritas sumber, dan bahwa setiap aturan butuh pemilik. (Survivorship: Nilai Mana yang Menang?)
- Saya tahu bahwa kecocokan tidak mewajibkan penggabungan, dan saya hanya menggabungkan jika ada pemenang yang jelas, setelah lebih dulu memutuskan apa yang terjadi pada rekaman-rekaman anaknya. (Kecocokan Tidak Mewajibkan Penggabungan, Aturan Penggabungan Saya: Pemenang yang Jelas)
- Pengetahuan untuk ujian: Saya tahu apa yang dilakukan penggabungan akun di Salesforce: hingga tiga rekaman, satu rekaman utama (principal), Created By dan Created Date tertua yang dipertahankan, sisanya masuk Tempat Sampah, dan objek contact point tidak ikut digabungkan untuk akun pribadi. (Apa yang Sebenarnya Dilakukan Penggabungan di Salesforce)
SDM-3: tampilan tunggal pelanggan
- Saya tahu bahwa resolusi identitas Data 360 menautkan profil-profil sumber menjadi profil terpadu dan menyimpan tautan baliknya: paling dekat dengan registri. (Resolusi Identitas Menjawab “Siapa?”)
- Pengetahuan untuk ujian: Saya memahami aturan pencocokan Data 360: semua kriteria dalam satu aturan harus cocok, dan aturan mana pun bisa cocok; lebih banyak kriteria untuk akurasi, lebih sedikit untuk konsolidasi. (Aturan Pencocokan)
- Saya memahami metode pencocokan (Exact, Exact Normalized, Fuzzy dengan tiga tingkat presisi): metode yang kurang presisi menaikkan konsolidasi, sekaligus risiko kecocokan palsu. (Aturan Pencocokan)
- Pengetahuan untuk ujian: Saya tahu bahwa aturan rekonsiliasi (Last Updated, Most Frequent, Source Priority) menentukan apa yang ditampilkan profil terpadu, tetapi tidak mengubah sumbernya; contact point tidak direkonsiliasi. (Rekonsiliasi Tetap Bukan Pengelolaan Master)
- Saya bisa memilih antara manajemen duplikat, resolusi identitas, dan platform MDM khusus sesuai pekerjaannya. (Tiga Alat untuk Tiga Pekerjaan)
MDM-4 dan data dua arah
- Saya tahu bahwa data dua arah tidak berarti dua master: suntingan di Salesforce atas bidang milik ERP adalah sebuah permintaan, jadi rancang alur minta → validasi → terima → terbitkan, dengan status tertunda. (Data Dua Arah Tidak Berarti Dua Master, Ketika Master Berkata Tidak)
- Saya tahu cara menghindari putaran dan tabrakan: membedakan perubahan asli dari gemanya, dan memutuskan bidang mana yang bergerak bersama sebagai satu transaksi. (Putaran dan Tabrakan)
- Untuk satu pelanggan di dua ERP, saya bisa memilih hierarki, akun yang setara, atau satu akun dengan satu rekaman anak per ERP, berdasarkan seberapa baik klien menjaga ERP-ERP-nya tetap sinkron. (Satu Pelanggan, Dua ERP, Tanyakan Bagaimana Mereka Menjaga ERP Tetap Sinkron)
Checkpoint 1: menyatukan Bagian 1
- Pengetahuan untuk ujian: Saya tahu lisensi eksternal mana yang membawa berbagi standar: Customer Community Plus dan Partner Community, yang butuh peran untuk pengguna eksternal; Customer Community memakai set berbagi. (Siapa Melihat Apa, dan Siapa Butuh Lisensi)
Di Luar Ujian
Section titled “Di Luar Ujian ”Ujian adalah batas bawah, bukan batas atas. Inilah kebiasaan dari bab ini yang dibutuhkan seorang arsitek, entah ada pertanyaan ujian tentangnya atau tidak.
- “Satu sumber kebenaran”: kebenaran yang mana? Itu sebuah arsitektur kebenaran, bukan satu rekaman.
- Buat otoritas terlihat di skema: sebuah awalan untuk bidang yang dimiliki sistem lain.
- Kepercayaan butuh lebih dari sekadar nilai: sumber, kapan terakhir dikonfirmasi, siapa yang mengubahnya.
- Mulailah dari masalahnya, bukan dari produk MDM. MDM adalah keputusan bisnis tentang otoritas.
- Menautkan bukanlah mengelola sebagai master.
- Di tempat kecocokan palsu itu mahal, lakukan pencocokan lebih sedikit dengan sengaja.
- Simpan duplikat dari muatan eksternal ketika Anda mungkin perlu menelusuri balik.
- Profil terpadu adalah sebuah peta. Golden record adalah sebuah keputusan.
- Penyajian bukanlah otoritas.
- Menyatukan identitas tidak menghapus batas keamanan.
- Yang paling sulit adalah yang dua arah. Otoritas yang dibagi bukanlah masalahnya; otoritas yang ambigulah masalahnya.
- Jangan pernah biarkan permintaan yang ditolak berubah menjadi kebenaran tandingan.
- Sebuah bidang yang menyatakan bahwa ini data master yang menentukan apakah rekaman bisa diedit, bukan tipe rekaman.
- Kita tidak mengendalikan ERP-nya. Yang kita kendalikan adalah cara kita merepresentasikannya di Salesforce.
Istilah Penting
Section titled “Istilah Penting ”| Istilah | Dalam satu baris |
|---|---|
| Manajemen data master (MDM) | Menetapkan dan mengatur identitas serta nilai otoritatif data kunci lintas sistem |
| Peta otoritas | Untuk setiap atribut: siapa yang membuatnya, siapa pemilik keputusannya, sistem mana yang otoritatif, siapa yang boleh mengubahnya |
| Golden record | Keputusan terkelola tentang nilai mana yang otoritatif |
| Golden record hibrida | Rekaman dengan sebagian atribut dikelola di tempat lain dan disalin masuk, dan sebagian dimiliki secara lokal |
| Registri | MDM yang menautkan rekaman sebagai entitas yang sama tanpa mengubah sumbernya |
| Konsolidasi | MDM yang menggabungkan data secara terpusat, biasanya untuk analitik, tanpa mengirim kembali |
| Koeksistensi | MDM yang memutuskan nilai master dan menerbitkannya kembali ke sumber-sumbernya |
| MDM terpusat | MDM di mana data yang dikelola dibuat di master lalu didistribusikan |
| Model data kanonis | Bentuk perusahaan yang disepakati untuk sebuah konsep, dipakai untuk memetakan sistem satu sama lain |
| Harmonisasi | Membuat nilai-nilai bisa dibandingkan: format, kode, dan singkatan standar |
| Pencocokan | Memutuskan apakah rekaman-rekaman mewakili hal yang sama |
| Survivorship | Aturan tentang nilai mana yang menang ketika sumber-sumber tidak sepakat |
| Rekaman utama (principal record) | Dalam penggabungan di Salesforce, rekaman yang bertahan dan mempertahankan bidang tersembunyi serta bidang baca-sajanya |
| Metode pencocokan (match method) | Cara sebuah kriteria pencocokan Data 360 membandingkan nilai: exact, exact normalized, atau fuzzy |
| Resolusi identitas | Pencocokan profil sumber menjadi profil terpadu di Data 360 |
| Profil terpadu | Sekumpulan kunci yang menautkan rekaman sumber yang mewakili satu orang atau perusahaan |
| Aturan rekonsiliasi | Aturan Data 360 tentang nilai mana yang ditampilkan profil terpadu |
| Hierarki dengan beberapa master | Hierarki yang cabang-cabangnya dimiliki oleh sistem yang berbeda |
Uji Diri
Section titled “Uji Diri ”Skenario singkat dengan gaya kursus ini. Tentukan jawaban Anda sebelum membukanya.
1. "Salesforce adalah satu sumber kebenaran kami untuk pelanggan." Apa yang Anda tanyakan?
Kebenaran yang mana? Otoritas berlaku per atribut: ERP mungkin memiliki nama resmi, alamat penagihan, dan batas kredit sementara Salesforce memiliki account executive dan tingkat success. Bangun peta otoritas. Baca lagi Kebenaran Dimiliki oleh Atribut.
2. Agen layanan perlu melihat bahwa sebuah kontak Salesforce adalah orang yang sama yang membeli secara online. Tidak ada yang butuh sistem-sistemnya berubah. Gaya MDM yang mana?
Registri: tautkan rekaman-rekaman itu sebagai satu identitas tanpa mengubah sumbernya, yang persis dilakukan oleh resolusi identitas Data 360. Pilih pola paling ringan yang menyelesaikan masalahnya. Baca lagi Registri: Beri Tahu Saya Siapa Adalah Siapa.
3. Survivorship diatur ke "yang paling baru menang" untuk setiap bidang. Seseorang mengubah salinan di Salesforce atas nama resmi milik ERP. Apa yang terjadi, dan apa yang salah?
Nilai terbaru menang, dan salinannya mengalahkan otoritasnya. “Paling baru” adalah pernyataan tentang kepercayaan yang cocok untuk sebagian atribut (nomor ponsel) dan tidak untuk yang lain. Di tempat peta otoritas menyatakan ERP memiliki bidang itu, ERP yang menang. Baca lagi Survivorship: Nilai Mana yang Menang?.
4. Rekaman pelanggan lama diimpor dan cocok dengan akun yang sudah ada. Gabungkan?
Berhati-hatilah. Kecocokan tidak mewajibkan penggabungan, dan penggabungan menghancurkan ID lama dan nilai-nilai lama yang mungkin perlu Anda telusuri. Tautkan saja, kecuali ada pemenang yang jelas dan duplikatnya tidak membawa apa pun yang Anda butuhkan. Baca lagi Aturan Penggabungan Saya: Pemenang yang Jelas.
5. Profil terpadu di Data 360 menampilkan Dallas. Tim berkata Dallas sekarang menjadi nilai emas untuk setiap sistem. Benarkah?
Tidak. Rekonsiliasi memutuskan apa yang ditampilkan profil terpadu; rekonsiliasi tidak mengubah sumbernya atau mengambil keputusan pengelolaan master. Jika setiap sistem harus memakai satu nilai yang dikelola, itu MDM koeksistensi atau terpusat, dengan seorang pemilik. Baca lagi Rekonsiliasi Tetap Bukan Pengelolaan Master.
6. Mencocokkan rekaman medis dibandingkan rekaman pemasaran: aturannya sama?
Tidak. Kecocokan palsu dalam pemasaran mengirim penawaran yang salah; dalam data medis, ia menggabungkan riwayat dua orang. Tetapkan ketatnya berdasarkan harga sebuah kesalahan, dan lakukan pencocokan lebih sedikit di tempat pencampuran itu mahal. Baca lagi Harga dari Sebuah Kesalahan.
7. Para sales ingin memperbarui alamat penagihan milik ERP dari Salesforce. Bagaimana Anda merancangnya?
Sebagai permintaan, bukan suntingan: Salesforce mengirim nilai yang diusulkan, ERP memvalidasi dan menerimanya, lalu menerbitkan kembali nilai otoritatifnya. Tahan status tertunda sampai saat itu, dan tangani penolakan, tabrakan, dan gema. Baca lagi Data Dua Arah Tidak Berarti Dua Master.
8. Di Steve Trucking, John Smith yang sama muncul di manifes dua Mitra Ritel. Satukan dia?
Tidak, dengan sengaja. Setiap mitra tidak boleh pernah melihat Penerima milik mitra lain, dan identitas terpadu adalah jembatan yang membocorkannya. Lakukan pencocokan lebih sedikit di tempat pencampuran itu mahal; jika sebuah mitra ingin Penerima berulang dikenali, batasi hanya untuk mitra itu. Baca lagi Apakah Saya Akan Menyatukan Penerima Lintas Mitra?.
9. Seorang sales mengirim nama jalan baru untuk alamat yang dimiliki ERP, sementara pada menit yang sama seseorang di ERP mengubah kotanya. Apa yang Anda putuskan?
Apakah alamat itu bergerak sebagai satu transaksi. Jika ya, semua bidangnya bergerak bersama atau tidak sama sekali, dan permintaan itu ditolak karena alamatnya sudah berubah sementara itu. Putuskan hal itu sebelum tabrakan pertama, dan ingat bahwa permintaan itu meminta agar nilai di ERP diubah, bukan mengubahnya. Baca ulang Putaran dan Tabrakan.
10. Seorang klien punya satu pelanggan di dua ERP, dan tidak ada yang menjaga kedua rekaman itu tetap sinkron. Tim penjualan ingin satu akun. Apa rekomendasi Anda?
Bukan satu akun. Jika mereka tidak bisa menjaga rekaman-rekaman itu tetap sinkron di ERP mereka sendiri, Salesforce tidak bisa melakukannya untuk mereka: representasikan sebagai akun yang setara atau sebagai hierarki, dan tampilkan struktur yang sudah dikenal tim penjualan. Satu akun dengan satu rekaman anak per ERP membutuhkan klien yang menjaga nilai-nilai bersama tetap sinkron. Baca ulang Tanyakan Bagaimana Mereka Menjaga ERP Tetap Sinkron.
Jelajahi
Section titled “Jelajahi ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Bantuan Salesforce (dicek 2026-09-25, bahasa Inggris): daftar resmi tujuan ujian dan bobotnya. Selalu periksa versi terkininya sebelum Anda mendaftar ujian.
- Bagian Jelajahi di setiap modul mencantumkan dokumentasi Salesforce di balik fakta-faktanya, beserta tanggal pengecekannya.