Model Data Adalah Kerangkanya

🌐 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)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 2 dari 7 dalam bab Berpikir seperti Data Architect, bab pertama kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Berpikir seperti Arsitek · Berikutnya: Uji Reversibilitas

Pertanyaan yang dijawab modul ini: Mengapa model data lebih penting daripada apa pun yang dibangun di atasnya, dan bagaimana cara menilainya?

Saat mengajar arsitektur data, ada satu ungkapan yang terus saya ulangi: model data adalah kerangkanya.

Model data adalah kerangka sebuah sistem. Semua hal lain dibangun di sekitarnya, dan dialah yang menyatukan seluruh tubuh. Anda tidak melihat tulang ketika memandang seseorang, tetapi tulanglah yang menentukan seberapa tegak orang itu berdiri, bagaimana ia bergerak, dan apa yang mampu ia angkat.

Pikirkan semua yang kita bangun dalam sebuah implementasi Salesforce. Kita membangun otomatisasi di sekitar model data. Kita menulis Apex terhadapnya, dan Flow yang membaca serta memperbaruinya. Kita membangun integrasi yang mengirim data ke dalamnya dan menarik data darinya. Kita membuat laporan dan analitik di atasnya, dan kita merancang keamanan di sekelilingnya. Dan makin lama, kita membangun agen AI yang perlu memahami data itu dan bertindak berdasarkannya. Semuanya bergantung pada struktur di bawahnya.

Itulah sebabnya membuat model data yang benar sejak awal sangat penting. Anda bisa mengubah tulangnya nanti. Tetapi kemungkinan besar akan terasa sakit.

Mulailah dari Bisnisnya

Model data yang baik dimulai dengan pertanyaan sederhana: apa yang sebenarnya perlu direpresentasikan oleh bisnis? Bukan “objek Salesforce apa saja yang kita punya?” Dan jelas bukan “apa yang bisa saya bangun dengan cepat?”

Kita berusaha memahami bisnisnya terlebih dahulu. Apa saja hal penting dalam bisnis ini? Bagaimana hubungan di antara semuanya? Siapa pemiliknya? Bagaimana semuanya berubah dari waktu ke waktu? Apa yang perlu diingat, dan apa yang digunakan bersama oleh berbagai proses bisnis? Baru setelah memahami hal-hal itu kita boleh mulai menerjemahkannya menjadi objek, bidang, dan hubungan.

Kedengarannya jelas. Dalam praktiknya, sangat mudah untuk terbalik. Seseorang melihat sesuatu yang mirip Peluang, Kasus, atau Aset, lalu langsung mulai merancang di sekitarnya. Kadang itu memang tepat. Kadang kita sedang memaksakan pasak persegi ke lubang bundar, dan begitu sudah cukup banyak yang dibangun di atas keputusan itu, mencabut pasaknya kembali menjadi sangat mahal.

Ini pertanyaan yang sering sekali saya dengar. Bisnis seorang pelanggan bisa punya banyak lokasi pengiriman. Haruskah setiap lokasi menjadi Akun, atau objek kustom? Sebelum menjawab, perhatikan apa yang perlu Anda ketahui lebih dulu: apa arti sebuah lokasi bagi bisnis ini, dan apa yang terjadi padanya. Itulah memodelkan bisnis sebelum memodelkan objek. (Jawaban saya ada di bab 3.)

Mendukung. Bertumbuh. Berkinerja.

Saat melihat sebuah model data, saya ingin model itu lulus tiga uji: mendukung bisnis, bertumbuh bersama bisnis, dan berkinerja.

Mendukung. Model harus mendukung apa yang sebenarnya ingin dicapai bisnis. Ada perbedaan besar antara model yang secara teknis bisa menyimpan data dan model yang benar-benar merepresentasikan bisnis dengan baik. Jika saya terus-menerus menambahkan bidang yang aneh, penanda khusus, otomatisasi yang rumit, dan pengecualian karena modelnya kurang pas, saya mulai bertanya apakah masalahnya benar-benar ada di otomatisasi. Mungkin modelnya yang salah. Model yang baik seharusnya membuat bisnis lebih mudah dipahami, bukan lebih sulit.

Bertumbuh. Ketika saya bilang bertumbuh, maksud saya bukan hanya lebih banyak rekaman. Volume memang penting: sepuluh ribu rekaman dan seratus juta rekaman menimbulkan masalah yang sangat berbeda. Tetapi bisnis juga bertumbuh dalam kompleksitas. Mereka menambah produk, memasuki pasar baru, mengakuisisi perusahaan, mengubah proses, menambah kanal, dan menghubungkan sistem baru. Mereka menemukan bahwa sesuatu yang dikira satu hal ternyata lima hal yang berbeda. Model yang bekerja dengan indah hari ini bisa menjadi jebakan jika tidak ada ruang untuk hari esok. Itulah sebabnya saya lebih suka desain yang bertumbuh lewat penambahan daripada desain yang terus mengubah apa yang sudah ada. Menambahkan sesuatu yang baru biasanya lebih mudah daripada mendefinisikan ulang sesuatu yang diandalkan oleh puluhan hal lain.

Berkinerja. Data tidak hanya diam. Kita menulisnya, mencarinya, mengkuerinya, membagikannya, membuat laporan darinya, dan mengintegrasikannya, dan makin lama sistem AI mengambilnya sebagai konteks sebelum bertindak. Sebuah model bisa terlihat indah di diagram tetapi tetap buruk sekali saat dioperasikan. Jadi kita merancang untuk cara data disimpan dan cara data akan digunakan.

Dan model itu harus terus berkinerja. Ia harus berkinerja dalam skala besar: ketika jumlah pengguna bertambah, ketika volume data bertambah, dalam kondisi dunia nyata dan pada puncaknya, di hari tersibuk dalam setahun, bukan di hari rata-rata. Dan ia harus tetap berkinerja ketika sesuatu yang tak terduga terjadi.

Mendukung. Bertumbuh. Berkinerja. Kita akan terus kembali ke tiga uji itu di sepanjang kursus ini.

Click to enlarge

Terlalu Datar, Terlalu Rumit, atau Memang Salah

Saya sudah melihat model data salah dalam tiga cara.

Yang pertama adalah memilih hal yang salah sejak awal. Kita memakai objek standar karena kelihatannya cukup mirip, lalu bertahun-tahun menambahkan pengecualian karena objek itu memang tidak pernah cocok. Itulah pasak persegi tadi.

Yang kedua adalah membuat model terlalu datar. Semuanya dimasukkan ke dalam satu objek, dan awalnya itu terasa sangat sederhana. Lalu bisnis bertumbuh, dan kita mendapati bahwa sebagian dari hal-hal itu memiliki siklus hidupnya sendiri, bisa memiliki beberapa instans, membutuhkan keamanannya sendiri, atau memiliki hubungannya sendiri. Tiba-tiba kita merepresentasikan hubungan satu-ke-banyak dengan Bidang 1, Bidang 2, dan Bidang 3, atau dengan penanda dan otomatisasi yang makin rumit. Model itu tidak menyisakan ruang bagi kita untuk bertumbuh.

Yang ketiga adalah kesalahan sebaliknya: kita melakukan normalisasi berlebihan. Kita membuat diagram yang elegan dengan objek demi objek, setiap konsep terpisah dengan sempurna. Indah secara teknis, menyiksa secara praktis. Pengguna kesulitan memahaminya, dan tata letak halaman serta halaman Lightning, dengan daftar terkait demi daftar terkait, bisa terasa dalam tanpa ujung. Kueri menjadi lebih rumit, otomatisasi melintasi lebih banyak hubungan, pelaporan menjadi lebih sulit, dan platform bekerja lebih keras untuk menjawab pertanyaan bisnis yang biasa-biasa saja.

Jadi mana yang benar, datar atau ternormalisasi? Tidak ada rumusnya. Anda menyimpan gambaran model yang optimal di kepala Anda dan memahami trade-off-nya saat Anda menjauh darinya. Itulah seni arsitektur, dan kita akan kembali membahasnya di modul 4 serta di bab berikutnya, saat kita belajar cara memodelkan. Untuk sekarang, sadari bahwa struktur itu sendiri adalah sebuah keputusan arsitektur.

Click to enlarge

Berhati-hatilah Saat Mengubah Kerangkanya

Begitu sebuah sistem sudah berjalan, saya menjadi sangat berhati-hati terhadap perubahan mendasar pada model data.

Misalkan sebuah bidang teks sudah ada selama bertahun-tahun, lalu seseorang berkata, “Kita sudah tidak memakainya seperti itu lagi. Ayo ubah menjadi angka.” Kedengarannya seperti perubahan bidang biasa. Tetapi apa saja yang bergantung pada bidang itu? Flow, Apex, laporan, integrasi, pipeline data, aplikasi eksternal, agen AI. Dan apa yang terjadi pada data historisnya? Platform sendiri tidak mengizinkan Anda mengubah tipe sebuah bidang selama kode atau flow masih merujuknya, dan itu menunjukkan seberapa jauh jangkauan perubahan tersebut.

Kadang jawaban yang tepat adalah tidak mengubah apa yang sudah ada. Tergantung seberapa besar perubahannya, saya lebih suka membuat sesuatu yang baru, bermigrasi secara terencana, lalu menghentikan struktur lama:

Tambahkan, jangan ubah. Hentikan secara bertahap, jangan mengejutkan.

Salesforce bahkan memberi Anda cara untuk menyatakannya di metadata: Field Usage sebuah bidang dapat diatur ke DeprecateCandidate, “direncanakan untuk dihentikan dan tidak lagi digunakan.” Itu menandai bidang tersebut bagi siapa pun yang membaca objeknya; bidang itu tidak disembunyikan, jadi mempensiunkannya tetap merupakan keputusan yang harus Anda jalankan.

Sebab begitu bagian lain dari arsitektur bergantung pada sesuatu, mengubah maknanya bisa jauh lebih berbahaya daripada mengubah namanya. Versi terburuknya adalah bidang yang namanya tetap sama sementara isinya berubah: semua yang ada di hilir masih memercayai namanya.

Click to enlarge

Bahkan hal sesederhana mencentang kotak Required pada sebuah bidang bisa menjadi bom waktu. Jika Anda sudah mengumpulkan data, sebagian rekaman tidak akan memiliki nilai di bidang itu. Lalu beberapa hari, minggu, atau bulan kemudian, seseorang memperbarui salah satu rekaman tersebut, dan penyimpanannya gagal karena bidang wajib itu, dan tidak ada yang tahu nilainya. Perubahan sederhana seperti menjadikan bidang wajib bisa membawa konsekuensi yang tidak diinginkan dan tertunda. Kita akan kembali ke Required, dan kapan sebuah nilai benar-benar diketahui, di bab 3.

Di luar ujian: AI juga membangun di atas kerangka yang sama. Minta alat AI membangun sebuah aplikasi, dan dalam hitungan menit ia akan menghasilkan objek, bidang, Flow, Apex, komponen, dan pengujian. Jika model data aslinya salah, kita tidak menghindari konsekuensi keputusan yang buruk; kita justru mempercepatnya, karena setiap lapisan yang dihasilkan adalah satu hal lagi yang bergantung pada struktur itu. Itulah sebabnya saya ingin arsitek manusia meninjau model data yang dihasilkan AI, memahaminya, dan bertanggung jawab atasnya. Modul 7 membahasnya lebih jauh.

Kerangkanya Dulu

Sepanjang kursus ini, kita akan membahas banyak teknologi: objek dan hubungan, volume data besar, kueri, integrasi, migrasi, transaksi, keamanan, Data 360, dan AI. Di bawah semua itu ada model data.

Jika model mendukung bisnis, bisa bertumbuh bersama bisnis, dan berkinerja untuk cara-cara kita akan menggunakan data, kita sudah membangun fondasi yang kuat. Jika fondasinya salah, semua yang datang sesudahnya menjadi lebih sulit.

Model data adalah kerangkanya. Arsitek harus sangat berhati-hati saat merancang kerangka itu. Mengubah struktur yang sudah ada bisa menimbulkan konsekuensi berantai.

Yang Diputuskan Arsitek di Sini

• Apakah model mendukung bisnis, bisa bertumbuh bersamanya, dan berkinerja untuk cara-cara data akan digunakan.
• Apakah sebuah konsep cocok dengan objek standar atau justru pasak persegi.
• Seberapa datar atau seberapa ternormalisasi model dibuat, dan mengapa.
• Apakah perubahan pada kerangka sebaiknya berupa penambahan, migrasi, atau penghentian bertahap, alih-alih perubahan di tempat.

Jelajahi

• Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Bantuan Salesforce (dicek 2026-10-02; dicek ulang 2026-10-12, bahasa Inggris): perubahan tipe mana yang bisa menghilangkan data, dan mengapa Anda tidak bisa mengubah tipe bidang yang dirujuk oleh Apex, flow, atau proses.
• Data Classification Metadata Fields (opens in a new tab), Bantuan Salesforce (dicek 2026-10-02; dicek ulang 2026-10-12, bahasa Inggris): nilai Field Usage (Active, DeprecateCandidate, Hidden), dan bidang klasifikasi lainnya.