Memodelkan Data Berdasarkan Makna
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 2 kursus Data Architect. Baca dulu enam modulnya; 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 adalah fondasi untuk bagian ujian Data Modeling and Database Design, yang mencakup seperempat ujian. Bab ini membahas cara berpikirnya; bab berikutnya, Arsitektur Data Salesforce, membahas bagaimana platform membangunnya. Jadi sebagian besar yang diuji tentang objek, bidang, dan hubungan membutuhkan kedua bab itu.
Untuk Ujian
Section titled “Untuk Ujian ”Poin-poin dari bab ini yang paling mungkin penting di ujian. Setiap poin dikaitkan dengan tujuan ujiannya dan bertaut ke tempat ia diajarkan. Centang satu per satu sambil berjalan.
DM-1: membandingkan teknik untuk merancang model data Salesforce
- Saya bisa menjelaskan perbedaan antara model data konseptual, logis, dan fisik, dan untuk apa masing-masing. (Wujudkan Model di Salesforce)
- Saya bisa menemukan kandidat entitas dalam sebuah persyaratan, dan membedakan orang yang menjalankan pekerjaan dari sepotong data. (Kata Benda Memberi Anda Kandidat Entitas)
- Saya bisa membaca dan menggambar notasi kaki gagak (crow’s foot): satu, banyak, dan tanda kedua untuk opsional atau wajib. (Membaca Garis, Opsionalitas Juga Penting)
- Saya bisa menyebutkan kardinalitas sebuah hubungan: satu-ke-satu, satu-ke-banyak, banyak-ke-banyak. (Tanyakan “Satu atau Banyak?”)
- Saya tahu bahwa hubungan banyak-ke-banyak menjadi entitasnya sendiri, dan di Salesforce biasanya menjadi objek penghubung dengan dua induk. (Hubungan Bisa Menjadi Sebuah Hal)
- Saya tahu kapan sebuah hubungan butuh riwayat (rekaman dengan tanggal mulai dan tanggal akhir) alih-alih bidang yang terus ditimpa. (Waktu Mengubah Hubungan)
- Saya bisa memilih ID unik yang baik, dan saya tahu mengapa kunci alami atau apa pun yang berisi informasi pribadi merupakan pilihan yang berisiko. (Lalu Kita Harus Membahas ID Unik)
- Saya tahu perbedaan antara kunci alami dan kunci pengganti, dan bahwa satu rekaman bisa membawa beberapa pengenal eksternal. (Kunci Alami dan Kunci Pengganti)
- Saya tahu bahwa bidang Auto Number adalah nomor yang mudah dibaca, bukan ID Salesforce rekaman. (Hubungan Bergantung pada ID Unik)
- Saya bisa menerapkan bentuk normal pertama, kedua, dan ketiga, dan mengenali bidang yang menyimpan beberapa nilai atau mengulang fakta tentang sesuatu yang lain. (Cara Sederhana Memikirkan 1NF, 2NF, dan 3NF)
- Saya bisa menjelaskan kapan melakukan denormalisasi dengan sengaja (pengguna, pelaporan, skala), dan berapa biayanya. (Rancang hingga Bentuk Normal Ketiga, Lalu Mundur Sedikit)
- Saya bisa memilih antara daftar pilihan dan lookup ke sebuah objek untuk sebuah daftar nilai. (Lookup atau Daftar Pilihan?)
- Saya tahu bahwa tipe laporan kustom mengizinkan paling banyak empat hubungan objek, dan mengapa itu penting untuk model yang dalam. (Lookup atau Daftar Pilihan?)
- Saya tahu kapan master-detail cocok (anaknya tidak pernah berganti induk) dan kapan lookup lebih aman, termasuk panduan Salesforce agar tidak lebih dari 10.000 anak pada satu induk. (Hubungan Menjadi Keputusan Platform)
- Saya tahu mengapa sebisa mungkin menghindari hubungan polimorfik. (Hubungan Menjadi Keputusan Platform)
- Saya tahu bahwa entitas bisnis tidak otomatis berarti objek kustom: ia bisa menjadi objek standar, bidang, konfigurasi, atau data yang tinggal di luar Salesforce. (Entitas Bisnis Tidak Otomatis Berarti Objek Kustom)
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.
- Lupakan Salesforce sejenak. Modelkan bisnisnya sebelum memetakannya ke Akun dan Kontak.
- Dengarkan kata yang menyembunyikan dua hal. Di Steve Trucking, “pelanggan” berarti Mitra Ritel dan Penerima.
- Model adalah bagian dari percakapan. Model pertama Anda tidak dimaksudkan untuk benar; ia dimaksudkan untuk menunjukkan di mana Anda salah.
- Beri nama pada garisnya. Dua model dengan kotak yang sama bisa berarti hal yang berbeda.
- Tanyakan “saat ini, atau dari waktu ke waktu?” untuk setiap hubungan.
- Unik, tidak berubah, tanpa makna, bukan PII.
- Letakkan fakta di tempatnya, lalu mundur sedikit dengan sengaja, dan tuliskan alasannya.
- Denormalisasi tidak menghilangkan kerumitan; denormalisasi memindahkannya. Ketahui siapa pemilik kebenarannya.
- Satu sumber kebenaran, banyak bentuk: layar, laporan, data warehouse, dan AI.
- Jangan merancang dari Setup. Gambarkan modelnya sebelum Anda mengklik New Custom Object.
- Telusuri setiap keputusan fisik ke belakang hingga sesuatu yang dibutuhkan bisnis.
Istilah Penting
Section titled “Istilah Penting ”| Istilah | Dalam satu baris |
|---|---|
| Entitas | Sesuatu yang dipedulikan bisnis dan datanya disimpan |
| Kandidat entitas | Kata benda yang mungkin menjadi entitas, setelah Anda menanyakannya |
| Atribut | Fakta yang menggambarkan sebuah entitas |
| Hubungan | Cara dua entitas terhubung, dinamai dengan bahasa bisnis |
| Kardinalitas | Berapa banyak dari yang satu berhubungan dengan berapa banyak dari yang lain |
| Opsionalitas | Apakah hubungan itu wajib, atau bisa nol |
| Kaki gagak (crow’s foot) | Tanda untuk “banyak” di ujung sebuah garis |
| Objek penghubung (junction) | Cara Salesforce membangun hubungan banyak-ke-banyak: anak dari kedua induk |
| Model konseptual | Apa yang ada dalam bisnis dan bagaimana hubungannya; tanpa Salesforce |
| Model logis | Datanya: atribut, ID unik, dan hubungan, masih belum terikat pada sebuah platform |
| Model fisik | Bagaimana platform akan membangunnya: objek, bidang, dan tipe hubungan |
| Kunci alami | Pengenal yang sudah ada dalam bisnis, seperti VIN sebuah truk |
| Kunci pengganti (surrogate) | Pengenal yang dibuat hanya untuk mengidentifikasi rekaman |
| Pengenal eksternal | ID milik sistem lain untuk rekaman yang sama, disimpan dan dipetakan |
| Normalisasi (1NF, 2NF, 3NF) | Meletakkan setiap fakta di tempatnya: satu nilai per bidang, fakta tentang seluruh kunci, tidak ada fakta tentang fakta lain |
| Denormalisasi | Menyalin atau meratakan data dengan sengaja, karena alasan yang bisa Anda sebutkan |
| Anomali pembaruan | Fakta yang sama disimpan di banyak tempat, sehingga satu perubahan membuat sebagian salinan salah |
Uji Diri
Section titled “Uji Diri ”Skenario singkat dengan gaya kursus ini. Tentukan jawaban Anda sebelum membukanya.
1. Pihak bisnis memberi tahu Anda bahwa sebuah kru mengendarai sebuah truk. Enam minggu kemudian, seseorang bertanya kru mana yang memegang truk 117 pada hari tertentu. Apa yang seharusnya ada di model?
Sebuah Penugasan Kru: hubungan antara kru dan truk sebagai rekamannya sendiri, dengan tanggal mulai, tanggal akhir, dan rutenya. Kru dan truk bersifat banyak-ke-banyak dari waktu ke waktu, dan bisnis peduli pada riwayatnya. Sebuah bidang di truk akan terus ditimpa. Baca lagi Waktu Mengubah Hubungan.
2. Sebuah tim mengusulkan memakai nomor telepon setiap Penerima sebagai ID unik, "karena unik." Apa jawaban Anda?
Itu gagal di uji-ujinya: nomor telepon berubah dan dipakai bersama, jadi tidak tetap dan tidak andal keunikannya, dan itu informasi pribadi yang akan tersalin ke setiap sistem yang terhubung ke rekaman tersebut. Pakai ID yang dihasilkan sistem dan tanpa makna, dan simpan nomor telepon sebagai atribut. Baca lagi Lalu Kita Harus Membahas ID Unik.
3. Sebuah Pengiriman punya bidang Item 1, Item 2, dan Item 3. Datang sebuah pengiriman dengan empat item. Apa masalah sebenarnya, dan perbaikannya?
Model itu menyembunyikan struktur berulang di dalam bidang (masalah bentuk normal pertama). Perbaikannya bukan bidang Item 4; perbaikannya adalah entitas Item Pengiriman, anak dari Pengiriman, sehingga setiap item menjadi sebuah rekaman. Baca lagi Bentuk Normal Pertama.
4. Setiap pengiriman menyimpan nama manajer pusat distribusi. Manajernya berganti. Apa yang salah?
Fakta tentang sesuatu yang lain (pusat distribusi) disimpan di pengiriman: masalah bentuk normal ketiga, dan kini menjadi anomali pembaruan di ratusan rekaman. Manajer seharusnya berada di pusat distribusi; pengiriman menunjuk ke pusat distribusi. Baca lagi Bentuk Normal Ketiga.
5. Jenis titik pemberhentian (hanya pengiriman, dengan pemasangan, dengan pengangkutan barang lama) butuh durasi, keterampilan kru, dan daftar periksa. Daftar pilihan atau objek?
Objek. Ia punya lebih dari satu kolom informasi, dikelola oleh bisnis, dan berubah sesuai jadwalnya sendiri. Status pengiriman, daftar label yang pendek dan stabil, tetap menjadi daftar pilihan. Baca lagi Lookup atau Daftar Pilihan?.
6. Para mitra menginginkan scorecard ketepatan waktu per wilayah, dan wilayahnya tinggal di pusat distribusi. Anda menyalin wilayah ke setiap pengiriman. Apa yang harus Anda putuskan?
Siapa pemilik kebenarannya, bagaimana salinannya tetap sinkron, dan apakah pengiriman lama harus menyimpan wilayah yang benar ketika pengiriman itu terjadi atau mengikuti pusat distribusi jika ia pindah. Denormalisasi memindahkan kerumitannya; denormalisasi tidak menghilangkannya. Baca lagi Kadang Pelaporan yang Menang.
7. Trik seperti Duduk bisa terhubung ke ratusan ribu hewan peliharaan. Master-detail atau lookup dari Trik Hewan Peliharaan ke Trik?
Lookup. Panduan Salesforce adalah tidak lebih dari 10.000 anak pada satu induk, dan trik yang populer akan melampauinya. Master-detail cocok untuk Trik Hewan Peliharaan ke Hewan Peliharaan, karena trik seekor hewan peliharaan tidak pernah berganti induk dan satu hewan peliharaan hanya menguasai sedikit trik; master-detail juga yang memungkinkan hewan peliharaan me-roll-up hitungan Trik Dikuasai-nya. Baca lagi Duduk, Diam, Modelkan.
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.