Rancang hingga Bentuk Normal Ketiga, Lalu Mundur Sedikit

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

Pertanyaan yang dijawab modul ini: Kapan saya sebaiknya sengaja menjauh dari model ternormalisasi yang bersih?

Di modul sebelumnya, saya meminta Anda merancang hingga Bentuk Normal Ketiga.

Sekarang saya akan meminta Anda melanggarnya.

Kadang-kadang.

Itu pembedaan yang penting. Ada perbedaan besar antara tanpa sengaja membangun model data yang berantakan dan dengan sengaja mendenormalisasi model yang bersih. Jika Anda tidak memahami di mana data seharusnya berada sejak awal, menyalinnya ke tempat lain bukanlah arsitektur. Itu sekadar duplikasi.

Tetapi begitu saya memahami model logis yang bersih, saya bisa mengambil keputusan sadar untuk membentuk data secara berbeda bagi orang dan sistem yang mengonsumsinya.

Rancang hingga bentuk normal ketiga jika memungkinkan. Lalu mundur sedikit jika perlu.

Perhatikan apa yang tidak dikatakan kalimat itu. Kalimat itu tidak mengatakan bentuk normal ketiga lebih mudah dipahami. Kadang justru lebih sulit: model yang sepenuhnya ternormalisasi bisa menyebarkan satu gagasan bisnis ke lima objek, dan orang yang memakainya harus menyusunnya kembali di kepala mereka. Normalisasi memberi tahu saya di mana setiap fakta seharusnya berada. Normalisasi tidak menjanjikan bahwa itulah bentuk yang paling mudah dibaca, dipakai, atau dilaporkan. Justru itulah sebabnya mundur sedikit adalah keterampilan desain, bukan kegagalan.

Mulailah dengan memodelkan kebenarannya. Lalu putuskan bagaimana kebenaran itu perlu disajikan.

Duduk, Diam, Modelkan

Kembali ke anjing-anjing itu, dan kali ini kita membuat beberapa pilihan yang disengaja.

Ras: daftar pilihan, atau tabel tersendiri? Jalankan melalui pertanyaan-pertanyaan yang akan saya berikan nanti di modul ini. Apakah ada lebih dari satu kolom informasi? Ya: setidaknya ukurannya. Berapa banyak nilainya? Klub-klub kennel mengakui beberapa ratus ras (American Kennel Club saja mencantumkan 205), jauh melewati patokan saya yang sekitar 20. Jadi Ras layak mendapat tabelnya sendiri, dan setiap anjing merujuk ke rasnya. Itu menjawab pertanyaan yang kita bawa sejak modul 1: Ras adalah kotak tersendiri.

Tingkat Keterampilan: daftar pilihan. Belajar, Baik, Ahli. Tiga label, tidak ada hal lain yang perlu dikatakan tentangnya, dan semuanya tidak akan berubah. Untuk itulah daftar pilihan ada.

Berapa banyak trik yang dikuasai setiap anjing? Jawabannya sudah ada di dalam model: hitung rekaman Trik Anjing milik anjing itu. Tetapi pelatih ingin angka itu ada di setiap laporan, untuk mengurutkan dan memfilter berdasarkan angka itu, tanpa membuat laporan lintas dua tabel. Jadi saya mundur sedikit, dan menyimpan hitungan Trik Dikuasai (Tricks Known) langsung pada anjingnya. Itu sebuah salinan. Kebenarannya tetap ada di Trik Anjing; hitungan itu adalah representasinya, dan harus tetap selaras. Salesforce memberi kita cara yang bersih untuk melakukan persis hal itu, dan kita akan melihatnya di modul 6.

Sekarang kejutannya: sekolah anjing itu mulai menerima kucing. Apa yang kita lakukan? Satu opsi: tambahkan tabel Kucing di sebelah tabel Anjing, dan Trik Kucing di sebelah Trik Anjing. Semuanya menjadi dua kali lipat: dua untuk setiap layar, dua untuk setiap laporan, dan pada hari mereka menerima kelinci, tiga. Opsi lainnya: mundur selangkah dan perhatikan bahwa seekor kucing punya pemilik, mungkin peternak, ras, tanggal lahir, dan, dengan kesabaran, satu atau dua trik. Fakta yang sama dan hubungan yang sama dengan anjing. Jadi kita melakukan generalisasi: Hewan Peliharaan (Pet), dengan Spesies (Species), anjing atau kucing. Setiap ras juga termasuk dalam suatu spesies, dan di situlah spesies benar-benar berada: Labrador adalah anjing. Hewan peliharaan membawa salinannya, dengan sengaja, sehingga setiap layar dan laporan bisa dimulai dengan “anjing atau kucing?” tanpa mencari rasnya. Satu lagi salinan yang disengaja, dan di modul 6 salinan ini mendapat tugasnya sendiri.

Itulah merancang untuk perubahan, dan itu sebuah trade-off. Lakukan generalisasi terlalu dini dan semuanya menjadi “Benda” yang samar dengan bidang tipe yang tidak dipahami siapa pun. Saya melakukan generalisasi ketika bisnis benar-benar membawakan jenis kedua, dan keduanya punya hampir semua kesamaan, seperti anjing dan kucing di sini. Jika kucing membutuhkan fakta yang sangat berbeda, saya akan berpikir dua kali.

Click to enlarge

Sekarang jenis pilihan yang sama di Steve Trucking, tempat taruhannya lebih tinggi.

Model Paling Bersih Belum Tentu Sistem Terbaik

Bayangkan sebuah kru di sebuah titik pemberhentian. Pengirimannya punya item-item. Pemasangannya punya daftar periksa. Setiap langkah butuh foto. Penerima menandatangani.

Model yang ternormalisasi itu indah: Pengiriman → Item Pengiriman → Daftar Periksa Pemasangan → Foto, masing-masing di tempatnya.

Lalu saya duduk bersama orang-orang yang benar-benar memakainya. Sebuah kru menutup sekitar sepuluh titik pemberhentian sehari, di halaman rumah orang, sering tanpa sinyal. Jika model saya yang indah itu membawa mereka melewati labirin layar dan daftar terkait hanya untuk menyelesaikan satu titik pemberhentian, saya punya masalah arsitektur.

Model data bukan satu-satunya hal yang sedang kita rancang.

Kita sedang merancang sebuah sistem.

Kadang Pengalaman Pengguna yang Menang

Inilah salah satu alasan saya kadang mundur dari model yang ternormalisasi sempurna: pengalaman pengguna.

Mungkin sebuah konsep secara teknis bisa menjadi entitasnya sendiri, tetapi memisahkannya menambah kerumitan yang nilainya sangat kecil. Mungkin sebuah induk dengan beberapa tingkat anak bersih secara akademis tetapi menyiksa untuk diisi dan dipelihara. Mungkin konsepnya kecil, stabil, dan sebagian besar dipakai sebagai pilihan.

Di sinilah saya berhenti hanya bertanya, “Di mana fakta ini secara teori seharusnya berada?” dan mulai bertanya, “Bagaimana sistem ini benar-benar akan digunakan?”

Itu tidak berarti setiap keluhan tentang satu klik tambahan langsung meratakan model. Itu berarti kemudahan penggunaan adalah masukan arsitektur yang sah.

Kadang Pelaporan yang Menang

Pelaporan adalah alasan umum lainnya.

Setiap Mitra Ritel menginginkan scorecard: pengiriman tepat waktu per wilayah, per bulan. Dalam model yang bersih, sebuah pengiriman tahu pusat distribusinya, dan DC tahu wilayahnya. Secara teknis, kita bisa menelusurinya.

Tetapi bisakah alat pelaporannya? Bisakah orang-orang yang membuat laporan sendiri? Bisakah mereka menjawab pertanyaannya tanpa arsitektur pelaporan yang lebih rumit daripada pertanyaan itu sendiri?

Saat itulah saya mungkin menyalin atau menurunkan wilayah ke pengiriman, lebih dekat ke tempat ia dikonsumsi.

Sekarang saya sudah memperkenalkan duplikasi. Jadi saya butuh satu pertanyaan lagi: siapa pemilik kebenarannya?

Jika nilai sumbernya berubah, apa yang terjadi pada salinan saya? Haruskah ikut berubah? Atau haruskah ia menyimpan apa yang benar ketika pengiriman itu terjadi? Itu persyaratan yang berbeda.

Denormalisasi tidak menghilangkan kerumitan.

Denormalisasi memindahkannya.

Lookup atau Daftar Pilihan?

Inilah contoh yang lebih kecil yang terus-menerus ditemui admin Salesforce. Pengguna perlu memilih dari sekumpulan nilai. Apakah saya membuat entitas lain dan menghubungkannya, atau memakai daftar pilihan?

Ambil status sebuah pengiriman: terjadwal, dimuat, dalam pengiriman, hampir tiba, terkirim, terpasang, pengecualian, dikembalikan. Daftar label yang pendek dan stabil. Daftar pilihan persis yang saya inginkan.

Sekarang ambil jenis titik pemberhentian: hanya pengiriman, pengiriman dengan pemasangan, pengiriman dengan pengangkutan barang lama. Yang satu ini membawa informasinya sendiri: berapa lama waktu di titik pemberhentian, keterampilan apa yang dibutuhkan kru, daftar periksa pemasangan mana yang berlaku. Ia berubah secara mandiri, dan bisnis mengelolanya. Itu entitas, bukan label.

Jika saya membuat objek untuk setiap konsep yang secara teori bisa dinormalisasi, saya bisa membangun sistem yang indah secara teknis tetapi tidak dinikmati siapa pun. Jika saya mengubah setiap konsep menjadi daftar pilihan karena mudah, saya bisa terpojok dengan sangat cepat.

Jadi saya bertanya: apakah ia punya informasinya sendiri? Hubungan? Apakah ia berubah secara mandiri? Apakah ia perlu dikelola sebagai data? Mungkinkah bisnis suatu saat butuh lebih dari sekadar label darinya?

Inilah pertanyaan-pertanyaan yang benar-benar saya ajukan dalam sesi desain.

Apakah ada lebih dari satu kolom informasi? Jika nilainya butuh deskripsi, durasi, daftar keterampilan, atau pemilik, ia bukan lagi sebuah label.

Berapa banyak nilainya? Patokan saya sekitar 20. Lebih dari 20 nilai, daftar pilihan mulai tidak efektif, dan sudah waktunya memikirkan objek. Negara bagian AS, yang berjumlah lima puluh, adalah pengecualian yang kita terima, dan daftar negara lebih buruk lagi; jujur saja, adakah yang suka daftar pilihan negara? Menurut saya itu menyebalkan.

Apakah nilainya dibuat dari waktu ke waktu, dan oleh siapa? Menambahkan nilai daftar pilihan adalah perubahan konfigurasi, yang berarti butuh admin. Jika bisnis menambah nilai setiap minggu, dan orang-orang yang menambahkannya bukan admin, daftar pilihan menaruh sebuah tiket di depan setiap nilai baru.

Apakah orang perlu memfilter dan membuat laporan berdasarkan nilai itu? Daftar pilihan sangat bagus untuk itu. Lookup tidak serapi itu. Setiap lookup menambah satu lompatan: sebuah tipe laporan hanya mengikuti rantai pendek objek terkait (tipe laporan kustom mengizinkan paling banyak empat hubungan objek), layarnya berubah menjadi daftar terkait di dalam daftar terkait, dan kodenya makin rumit.

Sebuah daftar nilai sering lahir sebagai daftar pilihan dan, seiring waktu, pantas menjadi objek tersendiri. Biarkan ia membuktikan kepantasannya.

Click to enlarge

Kadang Skala Mengubah Jawabannya

Desain yang bekerja dengan indah pada beberapa ribu rekaman bisa berperilaku sangat berbeda pada jutaan rekaman.

Jadi jangan hanya melihat diagramnya. Ketahui angkanya.

Steve Trucking melakukan sekitar satu juta pengiriman per tahun, dengan pertumbuhan 30 persen per tahun. Setiap pengiriman mengumpulkan sekitar delapan pembaruan status. Itu delapan juta rekaman status tahun ini, dan sekitar 13,5 juta per tahun pada tahun ketiga. Tambahkan empat atau lima juta foto per tahun.

Model yang sama. Arsitektur yang sangat berbeda.

Kita akan membahasnya jauh lebih dalam di Arsitektur dalam Skala Besar. Untuk sekarang, ingatlah: volume bisa mengubah keputusan pemodelan data. Hubungan yang benar secara logis belum tentu menjadi desain fisik terbaik di setiap skala.

Konsumen yang Berbeda Menginginkan Bentuk yang Berbeda

Sejauh ini kita memikirkan sistem operasional. Koordinator mengatur rute pengiriman. Kru menutup titik pemberhentian. Sistem berubah seiring bisnis berjalan.

Tetapi bisnis juga ingin menganalisis riwayat bertahun-tahun. Mitra dan wilayah mana yang sering terlambat? Bagaimana waktu pengiriman berubah? Seberapa sering pemasangan butuh kunjungan kedua?

Sistem analitis mungkin menginginkan informasi yang sama disusun secara berbeda. Anda akan mendengar istilah seperti data warehouse, fact, dimension, dan star schema. Kita tidak akan membedahnya di sini; di Steve Trucking itu adalah data warehouse Snowflake, dan kita akan membahasnya lagi nanti dalam kursus ini.

Untuk sekarang: konsumen yang berbeda bisa membutuhkan bentuk yang berbeda dari kebenaran yang sama.

AI Menambah Satu Konsumen Lagi

Dan sekarang ada satu konsumen lagi: AI.

Seorang Penerima mengirim pesan, “Kiriman saya di mana?” Sebuah asisten AI bisa mencari ini:

Pengiriman 10427, Rute 3312, Titik Pemberhentian 7, Truk 117, Jendela 13.00–15.00.

Aplikasi tradisional sama sekali tidak keberatan mengikuti hubungan-hubungan itu. Tetapi untuk menjawab Penerima, asisten itu butuh konteks yang dirakit dari beberapa tempat:

Mesin cuci piring Redrock Anda adalah titik pemberhentian ketujuh pada rute hari ini dari pusat distribusi Phoenix. Truknya tinggal tiga titik pemberhentian lagi, dan Anda masih dalam jendela waktu pukul 13.00–15.00.

Kita telah mengambil informasi dari beberapa entitas yang saling berhubungan dan merakit representasi yang lebih datar dan kaya konteks untuk satu konsumen tertentu.

Itu tidak berarti saya menghancurkan model ternormalisasi saya. Dan jelas tidak berarti “AI suka data datar, jadi masukkan semuanya ke satu objek raksasa.” Jangan lakukan itu.

Sumber kebenarannya tetap bersih. AI mendapat representasi yang dibuat untuk pekerjaan yang sedang dilakukannya. Ini gagasan yang sama dengan yang baru saja kita lihat pada analitik:

Satu sumber kebenaran bisa mendukung beberapa bentuk untuk dikonsumsi.

Kita akan membahas grounding dan pengambilan data jauh lebih dalam nanti dalam kursus ini.

Jangan Menciptakan Banyak Kebenaran

Ada bahaya di sini.

Jika saya menyalin wilayah ke pengiriman untuk pelaporan, mengirim versi yang diratakan ke Snowflake, dan membangun versi kaya konteks untuk asisten AI, mana yang benar?

Pertanyaan itu butuh jawaban. Saya ingin tahu di mana nilai yang otoritatif tinggal. Semua yang lain adalah representasi dari kebenaran itu untuk suatu tujuan.

Tempat itu adalah system of record (sistem pencatatan). Salinan yang didenormalisasi bisa bagus: layar titik pemberhentian, scorecard, Snowflake, dan konteks AI masing-masing bekerja lebih baik dengan bentuk yang dibuat untuknya, dan merujuk ke sana tidak masalah. Tetapi ketika sesuatu berubah, perubahannya dimulai di system of record, biasanya model relasional, dan mengalir ke luar ke setiap salinan. Tidak ada yang memperbaiki wilayah di Snowflake, atau mengedit konteks AI secara manual. Perbaiki di sumbernya, dan biarkan perubahannya mengalir.

Click to enlarge

Dan ini paling penting ketika data berubah. Jika sebuah pusat distribusi pindah ke wilayah lain hari ini, haruskah pengiriman bulan lalu menampilkan wilayah baru? Mungkin. Mungkin tidak. Untuk riwayat, saya mungkin butuh wilayah yang benar ketika pengiriman itu terjadi. Itu bukan lagi masalah sinkronisasi. Itu keputusan bisnis.

Itulah sebabnya denormalisasi tidak boleh terjadi secara kebetulan. Setiap fakta yang diduplikasi memunculkan pertanyaan tentang kepemilikan, sinkronisasi, riwayat, dan kepercayaan. Ini pemikiran trade-off dari Bab 1: ketahui apa yang Anda beli (layar yang lebih mudah, laporan yang lebih sederhana, konteks yang lebih baik untuk AI) dan apa yang Anda bayar (data duplikat, sinkronisasi, kepemilikan kebenaran yang lebih rumit). Dan karena kita memulai dari model logis yang bersih, kita bisa menunjuk setiap salinan dan berkata, “Saya tahu ini seharusnya ada di sana. Saya menaruh representasinya di sini karena persyaratan ini.” Itu keputusan yang bisa kita tinjau, tantang, dan tuliskan, agar arsitek berikutnya tahu alasannya.

Yang Diputuskan Arsitek di Sini

Saat mempertimbangkan denormalisasi, saya memutuskan:

• Di mana sumber otoritatif setiap fakta bisnis tinggal.
• Apakah model yang bersih menimbulkan masalah nyata bagi pengguna, pelaporan, skala, atau kinerja.
• Apakah representasi yang lebih sederhana sepadan dengan duplikasinya, dan bagaimana salinannya tetap tepercaya.
• Apakah nilai historis harus berubah ketika sumber saat ini berubah.
• Apakah analitik atau AI butuh bentuk data yang berbeda dari sistem operasional.

Titik awalnya tidak pernah berubah: ketahui di mana kebenaran seharusnya berada. Lalu, ketika persyaratannya membenarkan, bentuklah untuk disajikan.

Berikutnya, Salesforce kembali masuk ke gambar. Kita akan mengubah apa yang telah kita rancang menjadi model data fisik.

Jelajahi

• Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 Juni 2019 (dicek 2026-10-12, bahasa Inggris): tipe laporan kustom “dapat mencakup hingga 4 hubungan objek.”
• Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 Januari 2026 (dicek 2026-10-12, bahasa Inggris): “AKC mengakui 205 ras, termasuk tiga pendatang baru ini.”
• Sekadar hiburan: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (dicek 2026-10-12, bahasa Inggris): daftar ras dari federasi internasional, dalam sepuluh kelompok. Telusuri daftarnya dan Anda akan melihat mengapa Ras layak mendapat tabelnya sendiri.