Lebih dari Sekadar Database

🌐 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 1 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Berikutnya: Lihat ke Kapal Induk: Model Data Standar

Pertanyaan yang dijawab modul ini: Apa yang membuat Salesforce berbeda dari database tradisional?

Jika Anda sudah cukup lama menjadi admin Salesforce, Anda sudah tahu cara membuat objek. Setup, Object Manager, New Custom Object. Beri nama, tambahkan beberapa bidang, buat tata letak halaman, dan sepuluh menit kemudian pengguna sudah bisa bekerja dengannya.

Tetapi apa sebenarnya yang terjadi ketika Anda mengklik Save?

Jika Anda berlatar belakang database, Anda mungkin membayangkan Salesforce pergi dan membuat tabel baru. Tidak. Dan memahami alasannya adalah salah satu titik di mana Anda mulai beralih dari berpikir seperti admin atau developer menjadi berpikir seperti arsitek.

Salesforce tentu menyimpan data; ada database di bawahnya. Tetapi Salesforce bukanlah database dengan layar yang bagus di atasnya. Salesforce adalah platform aplikasi yang digerakkan metadata, dan pembedaan itu membentuk hampir setiap keputusan dalam kursus ini.

Platform Punya Bentuk

Di bab 2 kita membangun model tanpa memikirkan Salesforce sama sekali. Itu disengaja: kita mendengarkan kata benda, membangun model konseptual, menambahkan atribut, kunci, dan hubungan, lalu baru bertanya bagaimana Salesforce seharusnya mengimplementasikannya. Sekarang kita harus memahami apa yang menjadi pijakan implementasi kita.

Saya memakai ungkapan sederhana untuk ini: platform punya bentuk. Salesforce memberi kita objek, bidang, hubungan, keamanan, otomatisasi, API, transaksi, pelaporan, dan pencarian, dan semuanya saling terhubung. Ketika saya membuat sebuah objek, saya tidak hanya membuat tempat untuk menaruh baris data. Saya membuat sesuatu yang ikut serta dalam model keamanan, yang bisa ditindaklanjuti otomatisasi, yang diekspos oleh API, yang bisa dipakai laporan, yang bisa dihubungkan oleh objek lain, dan yang akan diandalkan oleh pengguna, integrasi, dan makin lama juga agen. Itu jauh lebih dari sekadar tabel.

Metadata Adalah Cetak Birunya

Pikirkan sebuah gedung. Ada gedungnya sendiri, dan ada cetak biru yang menggambarkannya: di mana dindingnya, di mana pintunya, bagaimana ruangan-ruangan terhubung. Salesforce bekerja dengan cara yang sama. Definisi objek adalah metadata. Definisi bidang adalah metadata. Sebuah hubungan adalah metadata. Sebagian besar yang kita konfigurasi di Setup adalah metadata, dan platform membacanya saat runtime untuk memberi org kita struktur dan perilakunya.

Salesforce menggambarkan jantung platformnya sebagai multitenant sekaligus digerakkan metadata: ketika kita mendefinisikan sebuah objek atau bidang, definisinya disimpan sebagai metadata, bukan sebagai tabel atau kolom fisik baru untuk org kita (Platform Multitenant Architecture (opens in a new tab)).

Saat mengajarkan ini, saya membuka kap mesinnya. Salesforce tidak membuatkan database baru untuk Anda setiap kali Anda menambah objek. Ia menambahkan sebuah rekaman ke tabel-tabelnya sendiri: tabel objek, tabel bidang, tabel data, dan tabel pivot untuk indeks dan hubungan, semuanya diberi kunci pengenal org yang memisahkan data org Anda dari data semua orang lain. Jadi menambah sebuah bidang hanyalah menambah sebuah entri. Itulah sebabnya Anda bisa membuatnya seketika, saat jam makan siang, di production.

Ini juga menjelaskan sesuatu yang sering membuat orang tersandung. Ketika Anda menulis SELECT Id, Name, Special__c FROM Account, kelihatannya seperti satu tabel. Di baliknya, Anda membaca objek standar dan bidang kustomnya dari struktur yang berbeda, jadi platform sedang melakukan join yang tidak pernah Anda tulis. Indeks memang ada, tetapi tidak bekerja seperti indeks di database tradisional. Anda tidak perlu tahu detail internalnya untuk ujian. Anda perlu tahu bahwa apa yang Anda lihat di Object Manager bukanlah gambaran satu-ke-satu dari tabel fisik, dan bahwa abstraksi itu adalah kekuatan platform sekaligus alasan ia berperilaku seperti itu.

Click to enlarge

Lihat ke Kapal Induk

Salah satu hal yang saya katakan di kelas adalah lihat ke kapal induk. Sebelum menciptakan cara rumit untuk melakukan sesuatu di Salesforce, lihat bagaimana Salesforce sendiri melakukannya.

Ambil Akun. Anda tidak membuatnya; Salesforce yang membuatnya. Tetapi Anda bisa menambahkan bidang ke dalamnya, membangun otomatisasi di sekitarnya, mengubah tata letaknya, mengeksposnya melalui API, dan menghubungkan objek lain dengannya. Objek kustom berjalan di mesin yang sama, itulah sebabnya objek standar dan kustom terasa sangat mirip saat kita membangun di atasnya. Di Apex, keduanya bahkan berbagi kelas dasar yang sama, sObject.

Itulah kebiasaan yang menjadi pijakan bab ini, dan di modul berikutnya kita benar-benar melihatnya: model data standar yang sudah dibangun Salesforce untuk Anda.

Kita tidak membangun di samping Salesforce. Kita memperluasnya.

API Anda Datang Bersama Objeknya

Buat sebuah tabel di database tradisional dan Anda punya sebuah tabel. Jika aplikasi lain perlu bekerja dengannya, seseorang punya pekerjaan tambahan. Buat sebuah objek di Salesforce, dan platform sudah memahaminya melalui lapisan aplikasi dan integrasinya: platform memakai metadata yang sama untuk menyediakan REST API dan SOAP API-nya, sehingga rekaman objek itu bisa dibuat, dibaca, diperbarui, dan dihapus melalui API tersebut begitu objek itu ada (Platform Multitenant Architecture (opens in a new tab)).

Saya tidak merancang API karena saya membuat sebuah objek. Platform sudah mengenal objeknya, bidang-bidangnya, tipenya, hubungannya, dan keamanannya. Itu salah satu alasan pengembangan di Salesforce bergerak begitu cepat. Itu juga sebabnya membuat sebuah objek adalah keputusan yang lebih besar daripada kelihatannya: Anda menyambungkan sebuah struktur ke seluruh platform aplikasi. Dan berlaku juga sebaliknya. Orang-orang dari SQL Server atau Oracle kadang bertanya kepada saya bagaimana memuat data langsung ke database-nya. Tidak bisa. Semuanya masuk melalui API.

Gedung Apartemen

Sekarang kata yang terus-menerus Anda dengar: multitenancy. Saya membayangkannya sebagai gedung apartemen.

Anda punya unit apartemen Anda. Perabot Anda milik Anda, dan kunci Anda seharusnya tidak bisa membuka pintu saya. Tetapi kita berbagi gedung: listrik, air, lift, lobi. Org Anda terasa seperti lingkungan Anda sendiri, dengan data Anda, objek Anda, otomatisasi Anda. Di baliknya, Salesforce menggambarkan setiap org sebagai penyewa (tenant), mengisolasi data, metadata, dan logika setiap penyewa sementara infrastruktur dan layanannya dipakai bersama (Platform Multitenant Architecture (opens in a new tab)). Begitulah Salesforce bisa memberi setiap pelanggan platform yang begitu bisa disesuaikan tanpa menjalankan tumpukan teknologi terpisah untuk masing-masing.

Tetapi berbagi gedung ada konsekuensinya. Jika satu penyewa membeli AC raksasa lalu menyalakan pengering rambut dan oven bersamaan, ia membuat sekringnya putus, dan seluruh lantai menjadi gelap.

Anda Tidak Boleh Menguasai Lift

Tinggallah di gedung itu sebentar lagi. Bayangkan seorang penghuni mengumumkan, “Saya butuh lift dari pukul delapan sampai pukul dua belas. Tidak ada orang lain yang boleh memakainya.” Itu tidak berlaku di gedung bersama, dan tidak berlaku pula di Salesforce. Satu penyewa tidak boleh dibiarkan memakai sumber daya bersama tanpa batas dan menurunkan kinerja platform bagi semua orang lain.

Dari situlah governor limit berasal. Jika Anda pernah mengembangkan di Salesforce, Anda mungkin mengenalnya sebagai daftar angka yang harus dihafal. Saya tidak ingin Anda memandangnya seperti itu. Salesforce menerapkan batas di tingkat transaksi dan org agar beban kerja satu penyewa tidak memonopoli komputasi bersama (Architecture Basics (opens in a new tab)). Itulah arsitekturnya; setiap batas individual hanyalah implementasinya. Nanti dalam kursus ini kita akan memedulikan batas tertentu karena batas itu mengubah sebuah desain. Untuk sekarang, ingat gedungnya: Anda punya kebebasan yang sangat besar untuk merenovasi apartemen Anda. Anda tidak boleh menguasai liftnya.

ID Salesforce Adalah Bagian dari Abstraksinya

Setiap rekaman Salesforce punya identitas yang dipahami platform, yaitu record ID, dan ia berlaku di setiap kemampuan: UI, API, laporan, otomatisasi.

Di bab 2 kita bilang kunci yang baik itu unik, tidak berubah, tanpa makna, dan bukan PII. ID Salesforce memenuhi itu untuk Salesforce. Tetapi ia tidak sama dengan kunci bisnis. Perusahaan Anda mungkin tetap punya nomor pelanggan ERP, nomor karyawan, atau nomor pesanan mitra yang bermakna lintas sistem. Jangan mencampuradukkan “Salesforce tahu rekaman mana ini” dengan “perusahaan tahu hal bisnis mana ini.” Itu dua masalah identitas yang berbeda, dan yang kedua akan muncul lagi di integrasi dan data master.

Objek Lebih dari Sekadar Penyimpanan

Inilah pergeseran yang ingin saya Anda lakukan sebelum sisa bab ini. Objek bukan sekadar tempat menyimpan data. Bidang bukan sekadar kolom, dan hubungan bukan sekadar foreign key. Saya memakai perbandingan dengan database saat mengajar, karena itu terhubung dengan apa yang sudah diketahui orang. Tetapi jika kita berhenti di situ, kita melewatkan arsitekturnya.

Objek yang kita pilih menentukan kemampuan apa yang ikut datang bersamanya. Tipe bidang memengaruhi validasi, integrasi, pencarian, pelaporan, dan bagaimana sistem lain membaca datanya. Hubungan menentukan siklus hidup, kepemilikan, berbagi, dan penghapusan. Di mana kita menaruh data memengaruhi penyimpanan, kinerja, dan skala. Dan karena semua ini berjalan di platform bersama, pilihan yang tidak berbahaya dengan seratus rekaman bisa berperilaku sangat berbeda dengan seratus juta. Kita akan membahas keputusan-keputusan itu satu per satu.

Di luar ujian: apa yang diubah AI. Selama bertahun-tahun, nama dan deskripsi yang baik membantu admin atau developer berikutnya memahami apa yang kita bangun. Sekarang mesin juga membaca konteks itu. Sistem AI yang bekerja dengan bidang bernama Flag2__c menghadapi masalah yang sama dengan developer baru: apa arti hal ini? Metadata bukan lagi hiasan; metadata adalah bagian dari cara mesin memahami aplikasi.

Yang Diputuskan Arsitek di Sini

• Apakah saya merancang untuk platform yang benar-benar saya pakai, atau memperlakukan Salesforce seperti database generik?
• Bagian mana dari desain saya yang merupakan konsep bisnis, dan mana yang merupakan pilihan implementasi Salesforce?
• Perilaku platform apa yang ikut datang bersama struktur yang akan saya buat?
• Batas mana yang merupakan ungkapan dari arsitektur bersama, dan mana di antaranya yang akan membentuk desain ini?
• Jika struktur ini akan sulit diubah nanti, apakah saya memperlakukannya sebagai keputusan arsitektur?

Di bab 2 kita bilang: jangan merancang dari Setup. Sekarang Anda tahu satu alasan lagi. Mengklik New Custom Object tidak sekadar memberi Anda sebuah tabel; itu menghubungkan satu lagi bagian arsitektur Anda ke platform multitenant yang digerakkan metadata. Tetapi sebelum memutuskan objek apa yang akan dibuat, ada pertanyaan yang lebih mendasar: apakah data ini memang seharusnya tinggal di sini? Itu berikutnya.

Jelajahi

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab), dicek 2026-10-02, dicek ulang 2026-10-12 (bahasa Inggris): definisi objek dan bidang disimpan sebagai metadata, bukan sebagai tabel baru; tabel bersama (MT_Objects, MT_Fields, MT_Data, MT_Indexes) dikunci dengan OrgID; metadata yang sama menyediakan REST API dan SOAP API.
• Salesforce Architects, Architecture Basics (opens in a new tab), dicek 2026-10-02, dicek ulang 2026-10-12 (bahasa Inggris): governor limit dan batas eksekusi agar kode dan transaksi “don’t monopolize shared compute resources” (tidak memonopoli sumber daya komputasi bersama).