Wujudkan Model di Salesforce
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)
Modul 6 dari 6 dalam bab Memodelkan Data Berdasarkan Makna, bab 2 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Rancang hingga Bentuk Normal Ketiga, Lalu Mundur Sedikit · Berikutnya: panduan belajar bab ini, lalu bab berikutnya: Arsitektur Data Salesforce
Pertanyaan yang dijawab modul ini: Bagaimana model data logis menjadi model data fisik di Salesforce?
Akhirnya kita akan membicarakan Salesforce. Jika selama ini Anda menahan keinginan untuk mengubah setiap kotak menjadi objek, sekarang Anda boleh. Tetapi perhatikan urutan yang kita tempuh: kita memahami bisnisnya, menggambarkan datanya, meletakkan setiap fakta di tempatnya, dan memutuskan di mana kita akan sengaja melenturkannya. Baru sekarang saya bertanya bagaimana Salesforce seharusnya mengimplementasikannya. Itulah urutan yang ingin saya Anda ingat: konseptual → logis → fisik. Model konseptual menggambarkan bisnis. Model logis menggambarkan data. Model fisik menggambarkan bagaimana kita benar-benar akan membangunnya.
Duduk, Diam, Modelkan
Section titled “Duduk, Diam, Modelkan ”Langkah fisik paling mudah dilihat pada sesuatu yang kecil, jadi hewan peliharaan lebih dulu.
Siapa bisnis dan siapa orangnya? Peternak adalah sebuah bisnis, jadi ia menjadi Akun dengan tipe rekaman Peternak. Pemilik juga sebuah Akun, atau akun pribadi, dengan tipe rekaman Pemilik. Dua jenis dari objek standar yang sama, berdampingan di bagian atas diagram, tepat di tempat mereka berada sejak modul 1.
Apa yang tidak punya tempat standar? Hewan Peliharaan, Ras, Trik, Trik Hewan Peliharaan, dan Penilaian Trik menjadi objek kustom. Dan ingat spesies yang kita salin ke hewan peliharaan di modul 5? Di sini ia mendapat tugasnya: ia menjadi tipe rekaman Hewan Peliharaan, Anjing atau Kucing. Satu objek dengan dua tipe rekaman, masing-masing dengan tata letak halaman dan nilai daftar pilihannya sendiri, bukan objek Anjing dan objek Kucing.
Hubungan mana yang master-detail? Saya memakai master-detail hanya jika anaknya tidak akan pernah berganti induk. Sebuah Trik Hewan Peliharaan menjadi milik hewannya seumur hidup, dan setiap Penilaian Trik menjadi milik Trik Hewan Peliharaannya, jadi keduanya master-detail. Itu langsung terbayar: master-detail-lah yang memungkinkan hewan peliharaan menyimpan ringkasan roll-up dari Trik Hewan Peliharaannya, sehingga hitungan Trik Dikuasai dari modul 5 tetap selaras dengan sendirinya. Namun hewan peliharaan bisa berpindah rumah, jadi Pemilik adalah lookup.
Mana yang lookup? Salesforce tidak menyarankan lebih dari 10.000 anak pada satu induk. Trik populer seperti Duduk, ras yang umum, atau peternak besar bisa dengan mudah melampauinya, jadi Trik Hewan Peliharaan merujuk ke Triknya dengan lookup, dan hewan peliharaan merujuk ke Ras dan Peternaknya dengan cara yang sama. Dan hindari hubungan polimorfik sebisa mungkin, yaitu jenis hubungan di mana satu bidang bisa merujuk ke beberapa tipe objek. Hubungan itu praktis di hari pertama dan lebih menyulitkan semua hal yang harus membacanya kelak: laporan, integrasi, dan kini agen.
Apa yang tetap di luar platform? Jika hewan peliharaan memakai kalung GPS yang melaporkan lokasinya, lokasi itu sama sekali tidak perlu disalin masuk. Ia bisa menjadi objek eksternal, dibaca langsung dari sistem pelacakan kalung itu.
Setiap keputusan pada diagram itu bisa ditelusuri kembali ke sesuatu yang kita putuskan sebelumnya, dan memang itulah intinya. Sekarang langkah yang sama untuk Steve Trucking.
Mulailah dari Model Logis
Section titled “Mulailah dari Model Logis ”Model logis Steve Trucking kita sekarang memuat Mitra Ritel, Pusat Distribusi, Manifes, Pengiriman, Item Pengiriman, Penerima, Rute, Titik Pemberhentian, Kru, Truk, dan Penugasan Kru. Itu semua konsep bisnis, dan sekarang saya bisa mulai memetakannya ke Salesforce.
Sebuah Mitra Ritel mungkin menjadi Akun. Sebuah pengiriman mungkin dipetakan ke sesuatu yang sudah dimiliki Salesforce untuk pekerjaan terjadwal di lapangan, atau mungkin menjadi objek kustom. Manifes tidak punya padanan standar yang cocok, jadi kemungkinan besar menjadi objek kustom. Dan Penerima adalah pertanyaan yang benar-benar sulit: Akun Pribadi, Kontak, atau sekadar informasi pada pengiriman? Kita akan menjawabnya dengan tuntas di bab berikutnya.
Kata yang penting tetap mungkin. Jangan mengasumsikan implementasinya hanya karena sebuah konsep bisnis terdengar seperti objek Salesforce. Itulah sebabnya kita membangun model logis lebih dulu: model itu memberi kita sesuatu untuk menguji desain Salesforce.
Entitas Bisnis Tidak Otomatis Berarti Objek Kustom
Section titled “Entitas Bisnis Tidak Otomatis Berarti Objek Kustom ”Inilah jebakan yang ingin saya hindari oleh para admin: “Kita mengidentifikasi sebelas entitas, jadi kita butuh sebelas objek kustom.” Tidak. Sebuah entitas logis memberi tahu kita bahwa konsep bisnis itu penting. Entitas itu tidak mendikte bagaimana Salesforce harus menyimpannya. Sebuah konsep bisa menjadi objek standar, objek kustom, hubungan antarobjek, satu atau beberapa bidang, nilai yang dikelola di konfigurasi, atau data yang sama sekali tinggal di luar Salesforce (foto-foto pengiriman Steve Trucking adalah kandidat yang baik untuk itu). Model fisik adalah tempat pilihan-pilihan itu diambil, dan justru itulah sebabnya kita tidak mengambilnya di panggilan pertama.
Atribut Menjadi Bidang Fisik
Section titled “Atribut Menjadi Bidang Fisik ”Peralihan yang sama terjadi pada atribut. Truk logis kita punya nomor unit, VIN, merek, model, tahun model, pelat nomor, dan status. Sekarang kita memutuskan bagaimana semuanya ada secara fisik: objek mana yang memilikinya, tipe bidang apa yang dipakai, mana yang wajib, mana yang harus unik, mana yang merupakan pengenal eksternal, mana yang butuh validasi, mana yang diturunkan alih-alih disimpan, dan mana yang sensitif. Di tingkat logis kita bertanya apa arti Truk. Di tingkat fisik kita bertanya bagaimana Salesforce akan merepresentasikan Truk. Pertanyaan yang berbeda.
Hubungan Menjadi Keputusan Platform
Section titled “Hubungan Menjadi Keputusan Platform ”Semua waktu yang kita habiskan untuk hubungan terbayar di sini. Kita sudah tahu apakah setiap hubungan bersifat satu-ke-satu, satu-ke-banyak, atau banyak-ke-banyak, wajib atau opsional, dan apakah riwayatnya penting. Sekarang kita memutuskan bagaimana Salesforce mengimplementasikannya: lookup, master-detail, atau Junction Object Salesforce, dan mungkin penghubung dengan atributnya sendiri, karena, seperti yang kita temukan, hubungan itu sendiri bisa punya makna bisnis.
Ingat kembali Penugasan Kru. Kita bisa saja memulai bab ini dengan berkata, “Mari buat Junction Object Salesforce antara kru dan truk.” Lihat apa yang akan kita lewatkan: mengapa hubungan itu ada, apakah ia butuh tanggal dan rute, apakah ia punya status, dan apakah klaim kerusakan berminggu-minggu kemudian butuh riwayatnya. Pertanyaan-pertanyaan bisnis itulah yang memberi tahu kita apa Penugasan Kru itu. Baru setelah itu kita boleh memutuskan bagaimana Salesforce membangunnya, dan apakah Salesforce sudah punya sesuatu yang bisa mengerjakannya.
Sekarang Gambarkan Model Fisiknya
Section titled “Sekarang Gambarkan Model Fisiknya ”Diagramnya berubah lagi. Model konseptual menampilkan konsep bisnis dan garis sederhana. Model logis menambahkan atribut, kunci, kardinalitas, dan entitas yang bersembunyi dalam hubungan. Sekarang model fisik mulai terlihat seperti Salesforce: objek standar, objek kustom, bidang, tipe hubungan, dan apa yang tinggal di luar platform.
Saya ingin Anda bisa menaruh ketiga diagram itu berdampingan dan melihat urutannya: bukan tiga diagram yang tidak berkaitan, melainkan bisnis yang sama di tiga tingkat.
Sedikit tentang cara saya menggambar diagram ini, karena tata letak adalah bagian dari pesannya. Saya menaruh objek utama di tengah, sedikit ke bawah. Jika ia punya objek induk, saya menaruhnya sedikit di atas, sehingga Anda membaca model dari atas ke bawah, dari kiri ke kanan, sesuai cara bisnis memikirkannya. Data referensi ditaruh di samping. Warna juga punya arti: saya selalu membuat Salesforce berwarna biru, dan saya memilih satu warna untuk sistem milik perusahaan itu sendiri, biasanya hijau, karena hijau warna yang ramah. Saya tidak memakai merah, dan kuning agak terlalu mencolok. Ketika sebuah model ditata seperti itu, model itu terasa “bernyanyi” bagi saya. Banyak diagram yang akan Anda temui sebenarnya hanyalah urusan mengatur ruang: bagaimana cara memarkir semua mobil di garasi yang sesak? Saya lebih suka melukis gambaran logis yang bisa ditangkap oleh pikiran.
Model Fisik Harus Menghormati Platformnya
Section titled “Model Fisik Harus Menghormati Platformnya ”Salesforce bukan database relasional generik. Salesforce punya pandangannya sendiri tentang hubungan, kepemilikan, keamanan, dan pelaporan. Salesforce punya batasan, perilaku kueri, dan otomatisasi, serta arsitektur yang memengaruhi bagaimana sebuah model berperilaku dalam skala besar. Jadi model logis yang tampak sempurna di papan tulis mungkin perlu berubah ketika menjadi fisik. Itu bukan berarti Salesforce menghalangi. Itu berarti platform punya bentuk, dan arsitek yang baik memahami bentuk itu. Bab berikutnya membahas persis hal itu.
Kadang, model fisik juga akan sengaja berbeda dari model logis yang bersih karena keputusan denormalisasi yang kita ambil di modul 5. Itu tidak apa-apa, asalkan kita bisa menjelaskan alasannya.
Jangan Merancang dari Setup
Section titled “Jangan Merancang dari Setup ”Ada satu kebiasaan yang ingin saya hentikan jika Anda memilikinya: memulai arsitektur data Anda di Setup → Object Manager → New Custom Object dan menemukan modelnya sambil jalan. Salesforce membuat penciptaan sesuatu luar biasa mudah; itu salah satu kekuatannya, dan salah satu alasan model data yang lemah tercipta begitu cepat. Beberapa klik dan Anda punya objek, beberapa klik lagi dan Anda punya bidang dan hubungan. Lalu data datang, flow dibangun, laporan dibuat, integrasi bergantung padanya, dan objek yang Anda buat dalam lima menit menjadi sangat mahal untuk diubah. Itulah Uji Reversibilitas dari Bab 1. Jadi sebelum Anda mengklik New Custom Object, gambarkan modelnya.
Fisik Tidak Berarti Permanen
Section titled “Fisik Tidak Berarti Permanen ”Ada alasan lain mengapa saya memisahkan ketiga model: teknologi berubah. Hari ini sebagian data Steve Trucking tinggal di Salesforce core. Besok sebagian mungkin tinggal di Data 360, data warehouse, atau sistem yang belum kita pilih, dan asisten AI butuh representasinya sendiri. Arsitektur fisik bisa berubah, sementara konsep bisnisnya tetap sangat stabil: Mitra Ritel, pengiriman, dan Penerima tetap ada. Itulah yang membuat model logis berharga. Model logis adalah deskripsi bisnis yang tahan lama dan tidak terikat pada implementasi hari ini.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”Saat mengubah model logis menjadi model fisik Salesforce, saya memutuskan:
- Entitas bisnis mana yang dipetakan ke kemampuan standar Salesforce, dan mana yang butuh objek kustom atau representasi lain.
- Bagaimana atribut logis menjadi bidang fisik, dan bagaimana hubungan diimplementasikan di platform.
- Di mana denormalisasi yang disengaja ditempatkan dalam desain fisik.
- Data mana yang seharusnya ada di Salesforce, dan mana yang seharusnya ada di tempat lain.
- Karakteristik platform mana yang mengharuskan model fisik berbeda dari model logis.
Yang paling penting, saya ingin bisa menelusuri setiap keputusan ke belakang. Jika Anda menunjuk sesuatu di model fisik saya dan bertanya, “Mengapa itu ada di sana?”, saya harus bisa membawa Anda kembali melalui model logis dan model konseptual ke sesuatu yang benar-benar dibutuhkan bisnis: bisnis → konseptual → logis → fisik.
Di luar ujian: apa yang diubah AI. AI kini bisa membawa sebuah dokumen persyaratan langsung menjadi objek dan bidang Salesforce dalam satu lompatan. Itu membuat urutannya makin penting, bukan makin tidak penting: jika AI melompat dari persyaratan ke konfigurasi, mintalah ia menunjukkan apa yang terjadi di antaranya: apa yang ia putuskan sebagai entitas, kunci mana yang dipilihnya, hubungan mana yang diasumsikannya, dan di mana ia melakukan denormalisasi. Itu semua keputusan arsitektur, dan arsitek tetap perlu melihatnya.
Kita memulai bab ini di panggilan pertama, mendengarkan kata benda, dan kita mengakhirinya dengan model fisik yang bisa kita telusuri kembali ke bisnis. Sekarang setelah kita memilih membangun di atas Salesforce, pertanyaan berikutnya masuk lebih dalam: platform data seperti apa sebenarnya yang menjadi pijakan kita?
Jelajahi
Section titled “Jelajahi ”- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (dicek 2026-10-02, bahasa Inggris): “konfigurasikan hubungan induk-anak dengan tidak lebih dari 10.000 anak untuk satu rekaman induk.” Ini pedoman tentang data skew, bukan batas mutlak; bab 7 membahasnya lebih dalam.
- Roll-Up Summary Field (opens in a new tab), Bantuan Salesforce (dicek 2026-10-12, bahasa Inggris): bidang ringkasan roll-up menghitung atau menjumlahkan rekaman detail melalui hubungan master-detail.