Gambarkan Hubungannya
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 2 dari 6 dalam bab Memodelkan Data Berdasarkan Makna, bab 2 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Dengarkan Kata Bendanya · Berikutnya: Bangun Model Logis
Pertanyaan yang dijawab modul ini: Bagaimana saya mengubah kandidat entitas menjadi model data konseptual?
Kita sudah punya kata-kata benda di papan. Sekarang saya ingin tahu tentang garis di antara kotak-kotak itu, karena kumpulan entitas sebenarnya belum menjadi model data. Hubunganlah tempat sebagian besar makna berada. Sebuah Mitra Ritel mengoperasikan pusat distribusi. Sebuah manifes memuat daftar pengiriman. Sebuah pengiriman ditujukan ke seorang Penerima. Sebuah kru menjalankan sebuah truk. Setiap pernyataan itu memberi tahu saya sesuatu tentang bisnis, dan setiap pernyataan memberi saya satu pertanyaan lagi untuk diajukan.
Mulailah dengan Bahasa Bisnis
Section titled “Mulailah dengan Bahasa Bisnis ”Saya masih belum ingin membicarakan Salesforce. Saya tidak bertanya apakah ini seharusnya hubungan lookup atau master-detail, tidak memikirkan Junction Object Salesforce, dan tidak memutuskan apa yang terjadi ketika rekaman induk dihapus. Saya berusaha memahami hubungan bisnisnya.
Ambil “sebuah Mitra Ritel mengoperasikan pusat distribusi.” Kedengarannya sederhana. Tetapi bisakah sebuah Mitra Ritel punya satu DC atau banyak? Di Steve Trucking, setiap Mitra Ritel mengoperasikan pusat distribusi regional di setiap wilayah yang dilayani Steve Trucking, jadi banyak. Bisakah sebuah DC menjadi milik lebih dari satu Mitra Ritel? Apakah sebuah DC penting dengan sendirinya, dengan staf dan riwayatnya sendiri, atau hanya sebuah alamat? Jika sebuah Mitra Ritel pergi, apakah kita masih peduli pada DC-nya?
Itu bukan pertanyaan Salesforce. Itu pertanyaan bisnis, dan jawabannya bisa mengubah model sepenuhnya.
Membaca Garis
Section titled “Membaca Garis ”Sebelum masuk lebih dalam, saya ingin memberi Anda bahasa yang akan kita pakai di setiap diagram mulai dari sini. Bahasanya kecil saja. Sebuah garis di antara dua kotak menyatakan bahwa keduanya berhubungan, dan tanda di ujung-ujungnya menyatakan berapa banyak.
Mulailah dengan garis polos, tanpa tanda sama sekali. Di situlah saya mulai di papan tulis: saya tahu dua kata benda ini berhubungan, saya hanya belum menanyakan bagaimana. Lalu ujung-ujungnya diberi tanda. Satu garis melintang, palang, berarti satu. Kaki gagak, ujung yang bercabang tiga seperti kaki burung, berarti banyak. Nanti di modul ini Anda akan melihat tanda kedua muncul di sebelah tanda pertama, sebuah palang atau lingkaran, dan tanda itu menjawab pertanyaan lain: bisakah jumlahnya nol?
Satu aturan yang perlu diingat: Anda membaca setiap tanda pada kotak yang disentuhnya. Tanda yang paling dekat dengan kotak adalah jumlah paling banyak; tanda berikutnya ke luar adalah jumlah paling sedikit.
Duduk, Diam, Modelkan
Section titled “Duduk, Diam, Modelkan ”Sebelum Steve Trucking, kembali ke anjing-anjing dari modul 1. Kita punya lima kotak: Pemilik, Peternak, Anjing, Ras, dan Trik. Sekarang saya bertanya tentang garis di antara kotak-kotak itu.
Satu atau banyak? Seorang pemilik bisa punya lebih dari satu anjing; Ana punya dua. Seekor anjing punya satu pemilik, setidaknya dalam model kita. Itu satu-ke-banyak: satu garis tegak di sisi Pemilik, kaki gagak di sisi Anjing. Peternak punya bentuk yang sama: satu peternak membiakkan banyak anjing.
Bisakah tidak ada sama sekali? Max berasal dari penampungan hewan, jadi ia sama sekali tidak punya peternak. Ujung Peternak mendapat lingkaran: seekor anjing punya nol atau satu peternak. Tetapi setiap anjing punya pemilik, jadi ujung itu mendapat garis tegak kedua: tepat satu.
Banyak-ke-banyak? Seekor anjing menguasai banyak trik, dan sebuah trik, misalnya Duduk, dikuasai banyak anjing. Itu banyak-ke-banyak, dan justru di situlah saya mencari konsep yang tersembunyi. Adakah sesuatu tentang anjing ini yang menguasai trik ini? Seberapa baik ia melakukannya, dan kapan ia mempelajarinya. Hubungan itu punya fakta sendiri, jadi ia menjadi sesuatu yang berdiri sendiri: Trik Anjing (Dog Trick), dengan nama anjing di depan dalam bahasa Inggris, karena anjinglah yang menggerakkannya.
Apa arti setiap garis? Seorang pemilik memiliki seekor anjing. Seorang peternak membiakkannya. Seekor anjing menguasai trik-triknya. Beri nama garis-garisnya, dan siapa pun bisa membacakan kembali model itu kepada Anda.
Saat ini, atau dari waktu ke waktu? Apakah ada yang peduli seberapa baik Bella melakukan Duduk hari ini, atau bagaimana ia sampai ke sana? Jika seorang pelatih memeriksanya setiap beberapa bulan, setiap pemeriksaan adalah rekaman tersendiri: sebuah Penilaian Trik (Trick Assessment), dengan tanggal, tingkat keterampilan, dan siapa yang memeriksa, di bawah Trik Anjing tempat ia berada. Bahkan hubungan yang telah menjadi sesuatu bisa punya riwayatnya sendiri.
Ras untuk sementara saya biarkan tidak terhubung. Itu masih pertanyaan dari modul 1, kotak tersendiri atau kata pada anjingnya, dan modul 4 akan menjawabnya.
Setiap pertanyaan itu bekerja dengan cara yang sama pada bisnis sungguhan. Sekarang mari kita ajukan semuanya kepada Steve Trucking.
Tanyakan “Satu atau Banyak?”
Section titled “Tanyakan “Satu atau Banyak?” ”Salah satu hal pertama yang ingin saya pahami tentang sebuah hubungan adalah kardinalitas-nya. Itu istilah database; pertanyaannya jauh lebih sederhana: berapa banyak dari yang ini bisa berhubungan dengan berapa banyak dari yang itu? Pada tingkat konseptual ada tiga pola dasar.
Ini langkah penting dalam prosesnya: ambil dua kata benda yang berbeda dan pahami hubungannya. Dalam sebagian besar situasi, hubungannya satu-ke-banyak, atau banyak-ke-satu. Hanya dalam keadaan langka Anda akan bertemu hubungan satu-ke-satu.
Satu-ke-banyak ada di mana-mana. Satu Mitra Ritel memiliki banyak pusat distribusi. Satu manifes memuat banyak pengiriman. Satu rute memiliki sekitar sepuluh titik pemberhentian. Ketika saya mendengar bahasa seperti itu, saya mulai menggambar garisnya.
Dan sekarang garis itu mendapat tandanya. Setiap ujung menyatakan berapa banyak kotak yang disentuhnya: palang untuk satu, kaki gagak untuk banyak. Bacalah dari setiap kotak: satu Mitra Ritel memiliki banyak Pusat Distribusi.
Hubungan satu-ke-satu memang ada, tetapi jarang, dan ketika saya menemukannya saya mengajukan beberapa pertanyaan. Apakah ini benar-benar dua kata benda yang berbeda, atau sebenarnya satu? Jika berbeda, apa hubungan satu-ke-satu di antara keduanya? Dan apakah selamanya akan satu-ke-satu, atau hanya satu-ke-satu saat ini? Ini pertanyaan kunci dalam merancang model data. Sebuah kru dan sebuah truk terlihat satu-ke-satu pada pagi hari mana pun: dua orang, satu truk, satu rute. Dalam sebulan, tidak demikian, dan di situlah hubungan paling menarik dalam model ini bersembunyi.
Hubungan banyak-ke-banyak sangat menarik, karena sering memberi tahu kita bahwa ada konsep lain dalam bisnis. Bisakah sebuah kru mengendarai lebih dari satu truk dari waktu ke waktu? Ya. Bisakah sebuah truk dikendarai lebih dari satu kru? Sepanjang masa pakainya, tentu saja. Jadi kru dan truk memiliki hubungan banyak-ke-banyak. Tetapi sekarang saya ingin tahu lebih banyak. Apakah bisnis peduli kapan sebuah kru memegang sebuah truk? Untuk rute mana, pada hari apa? Siapa yang membuat penugasannya? Jika hubungan itu sendiri membawa informasi yang kita pedulikan, kita telah menemukan satu konsep bisnis lagi: Penugasan Kru.
Itu kebiasaan memodelkan yang penting. Kadang hal yang paling menarik bukanlah salah satu kata benda yang pertama kita dengar. Ia bersembunyi dalam hubungan di antara dua kata benda.
Hubungan Bisa Menjadi Sebuah Hal
Section titled “Hubungan Bisa Menjadi Sebuah Hal ”Di sinilah saya ingin para admin mulai berpikir secara berbeda. Di Salesforce kita terbiasa membicarakan objek dan bidang, jadi mudah sekali menganggap kotak sebagai bagian yang penting dan garis sebagai pipa saluran. Tetapi hubungan itu sendiri bisa punya makna bisnis.
Ambil contoh sebuah pengiriman dan produk-produk di dalamnya. Sebuah pengiriman bisa membawa beberapa produk, misalnya mesin cuci dan mesin pengering. Sebuah produk, model kulkas yang sama, muncul di ribuan pengiriman. Cukup mudah. Tetapi bagaimana jika saya perlu tahu berapa banyak produk itu ada di pengiriman ini, apakah ia akan dipasang, atau apakah barang lamanya akan diangkut? Saya tidak lagi hanya tertarik pada hubungan antara Pengiriman dan Produk. Saya tertarik pada Item Pengiriman, dan konsep itu layak mendapat entitasnya sendiri.
Jika Anda datang dari Salesforce, Anda mungkin sudah berpikir, “Itu objek penghubung (junction).” Anda tidak salah. Tetapi saya tidak ingin memulai dari situ. Item Pengiriman adalah konsep bisnis sebelum menjadi Junction Object Salesforce. Bisnis dulu, implementasi kemudian.
Beberapa kebiasaan saya untuk entitas-entitas hubungan ini, di mana pun nanti ia dibangun.
Beri nama. Jika bisnis sudah punya kata untuknya, pakai kata mereka. Jika belum, ambil nama kedua induknya dan gabungkan. Bayangkan sebuah pesanan dan sebuah produk. Hal di antara keduanya adalah Order Item (item pesanan): pesanannya, dan item pada pesanan itu. Ia anak dari kedua induk, dan di Salesforce mungkin akan menjadi Junction Object Salesforce. Tetapi nama mana yang ditaruh di depan dalam bahasa Inggris: Item Order, atau Order Item? Lihat jenis data masing-masing induk. Produk adalah data referensi; pesanan bersifat transaksional, dan pesananlah yang menggerakkannya. Jadi namanya Order Item, atau Order Product, sama seperti Salesforce punya Opportunity Product. Di Steve Trucking namanya Item Pengiriman (Delivery Item). Nama yang menggerakkan diletakkan sebagai inti nama, dan rekamannya akan tersusun di sebelah pemiliknya di setiap daftar yang akan Anda lihat.
Beri kunci sendiri. Ada godaan untuk mengatakan bahwa Item Pengiriman diidentifikasi oleh Pengiriman ditambah Produk, lalu berhenti di situ. Itu kunci gabungan, dan kunci gabungan jauh lebih sulit ditangani: setiap sistem yang menunjuk ke rekaman itu harus membawa kedua bagiannya. Beri entitas hubungan itu pengenalnya sendiri, dan jadikan Pengiriman ditambah Produk sebagai aturan keunikan, bukan sebagai identitasnya.
Perhatikan apa yang tidak ada di sana: nomor seri. Jumlah dan nomor seri tidak termasuk dalam rekaman yang sama. Jumlah menghitung beberapa buah dari suatu barang; nomor seri mengidentifikasi satu barang tertentu. Jika bisnis butuh nomor seri, setiap unit menjadi rekamannya sendiri, dan lima kulkas berarti lima rekaman. Saya tidak melihat alasan untuk Item Pengiriman dengan Detail Item Pengiriman di bawahnya. Pilih salah satu: agregat dengan jumlah, atau satu rekaman per unit. Di sini, jumlahlah yang dipakai.
Waspadai atribut yang butuh riwayat. Sebagian entitas hubungan sudah final begitu dibuat: mesin cuci di pengiriman ini tetap mesin cuci di pengiriman ini. Yang lain terus berubah. Sebuah kru memegang truk 117 minggu ini, dan minggu depan truk itu pindah ke kru lain. Ketika hubungan berubah dan bisnis peduli pada keadaan sebelumnya, entitas hubungan itu butuh tanggal, dan Penugasan Kru-lah yang perlu diawasi. Tanyakan sejak awal apakah bisnis peduli pada saat ini atau dari waktu ke waktu; kita akan kembali membahasnya sebentar lagi.
Hubungan Punya Makna di Luar Kardinalitas
Section titled “Hubungan Punya Makna di Luar Kardinalitas ”“Satu-ke-banyak” belum cukup untuk memahami sebuah hubungan. Saya juga ingin tahu apa arti hubungan itu.
Sebuah pengiriman punya lokasi. Lokasi yang mana? Pusat distribusi tempat ia berangkat? Rumah Penerima yang ia tuju? Keduanya tidak bisa saling menggantikan. Dua model bisa punya kotak dan kardinalitas yang persis sama, dan garis-garisnya bisa berarti hal yang sama sekali berbeda. Itulah sebabnya model yang baik bukan sekadar kotak yang dihubungkan garis. Garis-garisnya butuh nama. Jika saya menyerahkan diagram saya kepada arsitek lain, ia seharusnya tidak perlu menebak arti sebuah hubungan, dan jika saya menunjukkannya kepada pihak bisnis, diagram itu harus memakai bahasa yang mereka kenali.
Opsionalitas Juga Penting
Section titled “Opsionalitas Juga Penting ”Ada pertanyaan lain yang tersembunyi di dalam “berapa banyak?”: apakah hubungan itu wajib? Bisakah sebuah pengiriman ada sebelum dimasukkan ke rute? Harus bisa: manifes tiba satu atau dua hari sebelum pengiriman, dan rute difinalkan malam sebelumnya. Bisakah sebuah pengiriman ada tanpa Mitra Ritel? Tidak; setiap pengiriman berasal dari manifes sebuah mitra. Itulah opsionalitas.
Sekali lagi, jangan langsung melompat ke kotak centang Required di Salesforce. Ada bedanya antara mengatakan “setiap pengiriman harus punya Mitra Ritel” dan mengatakan “Salesforce harus mewajibkan bidang Mitra Ritel saat rekaman dibuat.” Keduanya mungkin berakhir dengan implementasi yang sama, tetapi keduanya bukan pernyataan yang sama. Yang pertama adalah aturan bisnis; yang kedua adalah salah satu cara menegakkannya. Sebagai arsitek, kita ingin memahami yang pertama sebelum memutuskan yang kedua.
Di diagram, opsionalitas adalah tanda kedua di setiap ujung. Tanda yang paling dekat dengan kotak adalah jumlah paling banyak: palang untuk satu, kaki gagak untuk banyak. Tanda berikutnya ke luar adalah jumlah paling sedikit: palang lagi berarti setidaknya satu, lingkaran berarti bisa nol. Jadi setiap Pengiriman ada di tepat satu Manifes, dan sebuah Manifes memuat satu atau banyak Pengiriman. Sebuah Pengiriman ada di nol atau satu Titik Pemberhentian, belum ada sampai ia dimasukkan ke rute, dan sebuah Titik Pemberhentian menurunkan nol atau banyak Pengiriman.
Waktu Mengubah Hubungan
Section titled “Waktu Mengubah Hubungan ”Ini pertanyaan yang sering saya ajukan: maksud Anda saat ini, atau dari waktu ke waktu?
Sebuah kru menjalankan sebuah truk. Saat ini? Untuk rute hari ini? Selama dua orang itu bekerja bersama? Masing-masing menghasilkan model yang berbeda. Jika bisnis hanya peduli truk mana yang dipegang sebuah kru hari ini, modelnya bisa tetap sederhana. Jika bisnis butuh setiap truk yang pernah dikendarai sebuah kru, kapan, dan di rute mana, kita butuh riwayat, dan Penugasan Kru yang kita temukan tadi tiba-tiba menjadi sangat penting.
Ini sumber kesalahan pemodelan yang umum. Kita memodelkan keadaan saat ini karena itulah yang bisa kita lihat di layar. Lalu, berminggu-minggu kemudian, sebuah Mitra Ritel mengajukan klaim kerusakan dan seseorang bertanya, “Kru mana yang memegang truk 117 pada 17 Maret?” Dan kita mendapati bahwa kita telah menimpa jawabannya setiap kali penugasan berubah.
Salah satu cara menyimpan riwayat itu adalah menjadikan penugasan sebagai rekamannya sendiri. Ketika sebuah kru ditugaskan, kita membuat Penugasan Kru dengan tanggal mulai. Ketika penugasan berubah, kita memberi tanggal akhir pada rekaman lama dan membuat rekaman baru dengan tanggal mulainya sendiri. Sekarang “siapa yang memegang penugasan itu enam bulan lalu?” menjadi pertanyaan yang mudah dijawab, bukan penggalian riwayat bidang atau log perubahan data. Dan begitu sebuah kru sudah punya banyak penugasan, seseorang akan bertanya mana yang berlaku saat ini, jadi saya akan menambahkan penanda Active juga.
Jadi ketika seseorang menceritakan sebuah hubungan kepada saya, saya tidak hanya bertanya bagaimana hal-hal itu berhubungan. Saya bertanya: apakah hubungan itu berubah, dan apakah kita peduli pada riwayatnya?
Gambarkan Sebelum Mengonfigurasi
Section titled “Gambarkan Sebelum Mengonfigurasi ”Model Steve Trucking kita mulai berguna. Kita tahu hubungan mana yang satu-ke-banyak, di mana banyak-ke-banyak menyembunyikan konsep lain, hubungan mana yang opsional, dan mana yang berubah dari waktu ke waktu. Dan kita masih belum membuat satu objek Salesforce pun. Itu disengaja.
Diagram ini seharusnya bisa saya tunjukkan kepada pihak bisnis, dan mereka tidak perlu mengenal Salesforce untuk memberi tahu saya apakah diagram ini benar. Jika mereka tidak bisa memvalidasinya karena isinya penuh istilah Salesforce, saya sudah terlalu cepat masuk ke desain fisik.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”Saat mengerjakan hubungan-hubungan dalam model konseptual, saya memutuskan:
- Bagaimana entitas-entitas bisnis utama saling berhubungan.
- Apakah setiap hubungan bersifat satu-ke-satu, satu-ke-banyak, atau banyak-ke-banyak, saat ini dan dari waktu ke waktu.
- Apakah setiap hubungan wajib atau opsional.
- Apakah sebuah hubungan banyak-ke-banyak menyembunyikan konsep bisnis yang bermakna.
- Apakah hubungan itu berubah dari waktu ke waktu, dan apakah kita butuh riwayatnya.
Lookup atau master-detail, konfigurasi objek penghubung, perilaku cascade, dan berbagi adalah keputusan fisik; kita akan sampai ke sana. Saat ini kita masih menjawab pertanyaan yang lebih penting: bagaimana sebenarnya bisnis ini berjalan? Begitu kita memahami entitas dan hubungan di antaranya, kita bisa mulai menambahkan detail yang menggambarkannya. Saat itulah model konseptual kita mulai menjadi model data logis.