Bangun Model Logis

🌐 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 3 dari 6 dalam bab Memodelkan Data Berdasarkan Makna, bab 2 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Gambarkan Hubungannya · Berikutnya: Letakkan Data di Tempatnya

Pertanyaan yang dijawab modul ini: Bagaimana saya mengubah model konseptual menjadi model data logis?

Model konseptual memberi tahu kita apa saja yang ada di Steve Trucking dan bagaimana semuanya berhubungan: Mitra Ritel dan pusat distribusinya, manifes dan pengiriman, Penerima, rute dan titik pemberhentian, kru, truk, dan penugasan kru. Itu sudah cukup untuk percakapan yang sangat produktif dengan pihak bisnis. Tetapi pada akhirnya saya butuh detail lebih banyak. Apa yang perlu kita ketahui tentang sebuah pengiriman? Apa yang membedakan satu pusat distribusi dari yang lain? Bagaimana kita mengidentifikasi seorang Penerima? Apa yang menjadi milik penugasan kru, bukan milik kru atau truknya? Pertanyaan-pertanyaan itu menggerakkan kita dari model konseptual menuju model data logis, dan kita masih belum membangun Salesforce.

Duduk, Diam, Modelkan

Pertama, kembali ke anjing-anjing itu. Kita sudah punya kotak dan garisnya. Sekarang dua pertanyaan baru: apa yang kita ketahui tentang setiap hal, dan bagaimana kita membedakan yang satu dari yang lain?

Apa yang menggambarkannya? Seekor anjing punya nama dan tanggal lahir. Seorang pemilik punya nama, nomor telepon, dan alamat. Sebuah trik punya nama dan tingkat kesulitan. Setiap fakta diletakkan pada kotak yang digambarkannya.

Lalu penghubungnya. Seberapa baik Bella melakukan Duduk, dan kapan ia mempelajarinya: apakah itu menggambarkan Bella? Tidak juga; ia lebih mahir dalam beberapa trik dibanding yang lain. Apakah itu menggambarkan Duduk? Tidak; setiap anjing melakukan Duduk dengan cara berbeda. Itu menggambarkan Bella dan Duduk bersama-sama, jadi tempatnya di Trik Anjing: tingkat keterampilan dan tanggal dipelajari. Itulah alasan penghubung itu ada: sebagian fakta hanya milik pasangannya.

Anjing yang mana? Coba namanya dulu. Ada banyak anjing bernama Max, jadi nama tidak unik. Nomor telepon pemiliknya? Marcus punya dua anjing dengan nomor telepon yang sama, orang berganti nomor, dan itu data pribadi seseorang, yang akan tersalin ke setiap sistem yang pernah merujuk ke seekor anjing. Nomor microchip tampak lebih baik: unik, dan tidak berubah. Tetapi anak anjing yang baru mungkin belum dipasangi chip, dan kunci tidak boleh kosong. Jadi microchip tetap ada, sebagai sesuatu yang juga dipakai untuk mengenali anjing itu, dan anjing itu mendapat ID Anjing (Dog ID) sendiri: sebuah nomor yang mengerjakan satu tugas membosankan, yaitu membedakan anjing yang satu dari yang lain.

Click to enlarge

Itulah pertanyaan-pertanyaan yang sekarang akan kita ajukan kepada Steve Trucking, dan alasan nama, nomor telepon, dan microchip masing-masing tidak memadai berubah menjadi aturan yang sudah saya pegang selama bertahun-tahun.

Model Konseptual Memberi Tahu Apa yang Ada; Model Logis Memberi Tahu Apa Artinya sebagai Data

Ambil Truk. Apa yang perlu saya ketahui tentang sebuah truk? Mungkin nomor unitnya, VIN, merek, model, tahun model, pelat nomor, jarak tempuh saat ini, dan statusnya. Itulah atribut dari Truk.

Sekarang ambil Pengiriman. Mungkin nomor pesanan dari Mitra Ritel, tanggal pengiriman, jendela waktu yang dijanjikan, waktu kedatangan aktual, status, dan apakah pengiriman itu mencakup pemasangan atau pengangkutan barang lama. Sekali lagi, atribut.

Model konseptual memberi tahu kita bahwa Pengiriman itu ada. Model logis mulai memberi tahu kita apa arti sebuah pengiriman sebagai data. Satu kotak sederhana seperti Truk atau Pengiriman bisa mewakili sekumpulan bidang.

Click to enlarge

Meski begitu, di sebagian besar diagram kita kotak-kotaknya tetap sederhana, karena tiga alasan. Jumlah bidang terus bertambah. Bidang cepat usang. Dan setiap bidang punya detail yang sulit ditampilkan dalam model objek: nama API, label, tipe data, dan panjangnya. Detail-detail itu pasti akan dicatat, hanya saja tidak di model data pertama. Ketika menampilkan beberapa bidang kunci benar-benar membantu bercerita, saya akan menggambar model data terperinci: potongan yang terfokus, hanya dengan bidang-bidang yang penting bagi poinnya.

Atribut Harus Menggambarkan Entitasnya

Inilah pertanyaan sederhana yang saya pakai saat melihat sebuah atribut: apa yang digambarkan oleh ini? Merek truk jelas menggambarkan truk. Tetapi bagaimana dengan nama-nama anggota kru pada sebuah pengiriman? Apakah nama-nama itu menggambarkan pengiriman? Ataukah menggambarkan sebuah kru, yang punya penugasan kru, yang mencakup rute, yang memuat titik pemberhentian ini?

Di sinilah model data mulai menyingkap hal-hal yang terlihat sangat wajar di layar. Seorang koordinator berkata, “Saya ingin melihat nama-nama kru di pengiriman.” Itu persyaratan pengalaman pengguna yang sah. Tetapi itu belum tentu persyaratan untuk menyimpan nama-nama kru di pengiriman. Keduanya hal yang berbeda, dan kita akan kembali membahasnya bersama normalisasi. Untuk sekarang, biasakan diri bertanya hal apa yang sebenarnya digambarkan oleh fakta ini. Pertanyaan itu akan menyelamatkan Anda dari banyak masalah.

Lalu Kita Harus Membahas ID Unik

Atribut menggambarkan sesuatu. Tetapi ada masalah lain yang harus diselesaikan: bagaimana saya tahu yang mana yang mana?

Dua Penerima bernama John Smith. Apakah mereka orang yang sama? Mungkin; mungkin juga tidak. Nama tidak cukup. Alamat? Orang pindah rumah. Nomor telepon berubah. Alamat email berubah. Bahkan nama sebuah Mitra Ritel pun bisa berubah.

Ini membawa kita ke kunci: apa yang memungkinkan kita mengidentifikasi sesuatu secara unik dalam model kita. Ini area di mana saya punya pendapat yang cukup kuat selama bertahun-tahun. Untuk sebuah pengenal, saya ingin empat hal:

Unik. Tidak berubah. Tanpa makna. Bukan PII.

Unik. Sebuah pengenal harus mengidentifikasi tepat satu hal. Jika dua pengiriman bisa punya nilai yang sama, itu bukan pengenal pengiriman yang andal. Nama biasanya tidak unik, alamat belum tentu unik, dan nomor telepon dipakai bersama. Bahkan nilai yang terlihat unik hari ini mungkin tidak lagi unik begitu datanya cukup banyak. Jadi tanyakan: mungkinkah dua dari ini punya nilai yang sama? Jika jawabannya ya, berhati-hatilah sekali memakainya sebagai ID unik rekaman.

Tidak berubah. Yang satu ini sering terlewat. Jika kita mengidentifikasi sebuah Mitra Ritel dari namanya dan mitra itu berganti nama, apakah kita mendapat mitra baru? Tidak. Entitas bisnisnya tetap sama; salah satu atributnya yang berubah. ID unik sebuah rekaman harus bertahan dari perubahan pada hal yang diidentifikasinya, dan itu menyingkirkan nama, alamat email, nomor telepon, alamat, dan nama pengguna, seberapa pun praktisnya semua itu terlihat ketika kita pertama kali membangun sebuah sistem.

Tanpa makna. Ini terdengar aneh saat pertama kali Anda mendengarnya. Mengapa saya ingin pengenal yang tidak bermakna? Karena makna berubah. Bayangkan seseorang membuat ID pengiriman yang menyandikan DC, Mitra Ritel, tanggal pengiriman, dan nomor urut: PHX-KEY-20261002-0042. Kelihatannya cerdas. Lalu Penerima menjadwalkan ulang ke hari Jumat. Apakah kita mengubah pengenalnya? Jika tidak, pengenal itu berbohong kepada kita. Jika ya, kita telah mengubah ID unik pengiriman karena salah satu atributnya berubah, dan setiap sistem yang menyimpan ID lama baru saja kehilangan jejaknya. Pengenal itu mencoba melakukan dua pekerjaan: mengidentifikasi pengiriman dan menggambarkannya. Saya lebih suka membiarkan atribut yang menggambarkannya dan membiarkan pengenal melakukan satu pekerjaan yang membosankan: mengidentifikasinya. Pengenal yang membosankan adalah pengenal yang baik.

Bukan PII. Yang satu ini cukup penting sehingga saya memisahkannya. Jangan memakai informasi identitas pribadi (PII) sebagai pengenal hanya karena terlihat unik. Di Steve Trucking ada godaan untuk mengenali Penerima dari nomor teleponnya. Tetapi sebuah kunci disalin ke mana-mana tempat sistem perlu menghubungkan rekaman: integrasi, ekspor, log, file status yang dikirim balik ke Mitra Ritel, data warehouse, data uji. Jadikan nomor telepon sebagai kunci, dan Anda telah menyebarkan data pribadi seorang Penerima ke seluruh arsitektur.

Sebuah kunci juga harus ada untuk setiap rekaman: tidak pernah null atau kosong. Jika sebagian orang tidak mau, atau seharusnya tidak perlu, memberikan suatu nilai, nilai itu tidak bisa menjadi kunci. Itulah sebabnya sistem menerbitkan pengenal internalnya sendiri, dan data pribadi, jika memang Anda butuhkan, menjadi atribut yang dilindungi.

Jadi aturan saya: unik, tidak berubah, tanpa makna, bukan PII.

Kunci Alami dan Kunci Pengganti

Orang-orang database punya nama untuk sebagian dari ini. Kunci alami sudah ada dalam data bisnis: VIN sebuah truk adalah contoh yang baik. Aplikasi kita tidak menciptakannya, dan ia sudah punya makna. Kunci pengganti (surrogate key) dibuat khusus untuk mengidentifikasi rekaman; ia tidak menggambarkan apa pun, ia hanya mengidentifikasi.

Di sebagian besar arsitektur, saya lebih suka kunci pengganti sebagai record ID internal dan menyimpan pengenal alami yang penting sebagai atribut. Itu tidak membuat pengenal alami menjadi buruk; pengenal alami sering sangat penting. Saya hanya tidak otomatis menjadikannya ID unik rekaman. Tanyakan apa yang terjadi jika nilainya dikoreksi, diformat ulang, diganti, dipakai ulang, hilang, atau datang dari lebih dari satu sistem sumber. Di situlah keputusan yang tampak sederhana menjadi keputusan arsitektur.

Satu Hal Bisa Punya Beberapa Pengenal yang Berguna

Record ID internal belum tentu pengenal yang dipakai setiap sistem lain. Steve Trucking mungkin mengidentifikasi sebuah pengiriman secara internal dengan ID yang dihasilkan sistem. Setiap Mitra Ritel mengenal pengiriman yang sama dengan nomor pesanannya sendiri: Keystone di manifes CSV-nya, Redrock di API-nya, Brightwave di pesan EDI-nya. Dan riwayat delapan tahun di RouteDesk, alat dispatch lama, memakai ID pengiriman milik RouteDesk sendiri.

Pengenal-pengenal itu penting. Kita perlu menyimpannya dan memetakannya dengan benar, karena pembaruan status harus kembali ke setiap mitra dengan nomor miliknya. Tetapi semuanya tidak harus menjadi ID unik pengiriman. “Apa ID-nya?” bisa punya lebih dari satu jawaban, dan arsitek harus tahu ID mana yang otoritatif dalam konteks mana. Kita akan kembali membahas ini bersama data master dan integrasi.

Hubungan Bergantung pada ID Unik

Sekarang kembali ke garis-garis yang kita gambar. Sebuah manifes memuat daftar pengiriman. Seorang Penerima menerima pengiriman. Sebuah kru punya penugasan kru. Hubungan-hubungan itu hanya berfungsi karena kita bisa mengidentifikasi hal-hal di kedua ujungnya dengan andal.

Di sinilah masalahnya terasa di Steve Trucking. Sebuah Mitra Ritel merevisi manifesnya di hari yang sama: sebuah pesanan dibatalkan, sebuah barang ditukar, sebuah alamat baru. Jika kita tidak bisa mencocokkan baris yang direvisi dengan pengiriman yang sudah kita punya, berdasarkan nomor pesanan mitra, kita membuat pengiriman kedua untuk kulkas yang sama, dan sebuah kru mungkin datang dua kali. Kotak, atribut, kunci, dan hubungan bukanlah gagasan yang terpisah. Semuanya bagian dari model yang sama.

Click to enlarge

Pada titik ini Anda mungkin berpikir, “Salesforce memberi setiap rekaman sebuah ID.” Benar, dan kita akan sampai ke sana. Jika datanya tinggal di Salesforce, setiap rekaman mendapat ID yang dihasilkan Salesforce. ID itu kriptik dan sulit dibaca, jadi biasanya kita juga menyediakan bidang ID yang bisa dipakai orang, seperti nomor pengiriman D-000184227, sebuah bidang Penomoran Otomatis (Auto Number). Orang sering mengira nomor itu adalah ID rekamannya, padahal bukan: ID Salesforce tetap ada di baliknya. Sistem atau database eksternal, Oracle atau SQL Server, juga punya ID uniknya sendiri. Tetapi arsitekturnya pada akhirnya bisa mencakup Salesforce, ERP keuangan, Snowflake, Data 360, sistem para mitra, dan sistem yang belum ada. Model logis menggambarkan data bisnis tanpa membuat setiap keputusan bergantung pada satu teknologi. Bagaimana Salesforce mengimplementasikannya secara fisik adalah langkah berikutnya.

Yang Diputuskan Arsitek di Sini

Saat mengubah model konseptual menjadi model logis, saya memutuskan:

• Atribut mana yang benar-benar menggambarkan setiap entitas.
• Bagaimana setiap entitas diidentifikasi secara unik, dan apakah pengenal itu cukup stabil untuk menjadi ID uniknya.
• Pengenal bisnis mana (nomor pesanan mitra, ID lama) yang perlu disimpan dan dipetakan.
• Apakah informasi sensitif sedang dipakai sebagai kunci.
• Apakah hubungan menghubungkan entitas melalui ID unik yang andal.

Sekarang kita punya entitas, hubungan, atribut, dan ID unik: cikal bakal model data logis yang sesungguhnya. Tetapi masih ada masalah. Sangat mudah menaruh data yang sepenuhnya valid di tempat yang salah. Di situlah normalisasi berperan.

Jelajahi

• Custom Field Types (opens in a new tab), Bantuan Salesforce (dicek 2026-10-09, bahasa Inggris): Auto Number memberi setiap rekaman nomor unik dengan format tampilan seperti awalan dan nol di depan; nomor itu bukan ID Salesforce rekaman tersebut. Lihat juga Auto-Number Fields Are Not Always Sequential (opens in a new tab) (dicek 2026-10-09, bahasa Inggris).