Letakkan Data di Tempatnya

🌐 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 4 dari 6 dalam bab Memodelkan Data Berdasarkan Makna, bab 2 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Bangun Model Logis · Berikutnya: Rancang hingga Bentuk Normal Ketiga, Lalu Mundur Sedikit

Pertanyaan yang dijawab modul ini: Bagaimana normalisasi membantu saya menentukan di mana data sebenarnya seharusnya berada?

Kita sudah punya model logis: entitas, hubungan, atribut, dan kunci. Sekarang saya ingin mengajukan salah satu pertanyaan terpenting dalam pemodelan data: apakah data ini memang seharusnya berada di sini?

Kedengarannya sederhana. Ternyata tidak. Saya sudah melihat banyak sistem di mana setiap bidang masuk akal ketika seseorang membuatnya. Masalahnya bukan bidang-bidangnya konyol; masalahnya fakta-faktanya disimpan di tempat yang salah. Sebuah pengiriman menyimpan informasi yang sebenarnya menggambarkan pusat distribusi. Alamat yang sama muncul di ratusan rekaman. Satu bidang menyimpan tiga nilai yang dipisahkan koma. Perubahan pada satu fakta bisnis berarti memperbarui 10.000 rekaman. Itulah masalah yang dibantu diselesaikan oleh normalisasi, dan sebelum kita tenggelam dalam istilah database, inilah seluruh gagasannya: letakkan sebuah fakta di tempatnya. Semua hal lain dalam modul ini membantu kita melakukannya dengan lebih sistematis.

Apa Itu Normalisasi?

Normalisasi adalah menata data sehingga setiap fakta disimpan sekali, di tempat yang seharusnya. Ketika satu tabel mengerjakan terlalu banyak tugas, kita memecahnya menjadi tabel-tabel yang masing-masing menggambarkan satu hal, dan kita menghubungkannya dengan kunci.

Mengapa repot-repot? Karena fakta yang disimpan sekali adalah fakta yang kita ubah sekali. Normalisasi mencegah redundansi, yaitu fakta yang sama disalin ke banyak rekaman, dan bersamanya ketidakkonsistenan yang menyusup ketika satu salinan diperbarui sementara yang lain tidak. Itulah sebabnya normalisasi cocok untuk sistem transaksional seperti Salesforce, di mana rekaman dibuat dan diperbarui sepanjang hari.

Kita menormalisasi secara bertahap dalam langkah-langkah yang disebut bentuk normal, dan masing-masing mengajukan satu pertanyaan:

• Bentuk normal pertama (1NF): satu nilai per bidang, dan sesuatu yang mengidentifikasi setiap baris secara unik.
• Bentuk normal kedua (2NF): setiap fakta menggambarkan keseluruhan dari apa yang mengidentifikasi baris itu, bukan hanya sebagiannya.
• Bentuk normal ketiga (3NF): setiap fakta menggambarkan hal ini, bukan sesuatu lain yang berhubungan dengannya.

Masih ada bentuk-bentuk lain setelah yang ketiga. Saya akan menyinggungnya nanti, termasuk mengapa kita biasanya berhenti di bentuk ketiga. Pertama, mari kita lihat ketiga langkah itu terjadi.

Mengapa Kita Menormalisasi?

Ketika saya mengajarkan ini secara langsung, saya tidak mulai dengan pengiriman. Saya mulai dengan anjing. Semua orang paham anjing, jadi tidak ada yang terganggu oleh urusan bisnisnya, dan kita bisa melihat data berusaha menemukan rumahnya. Lalu kita bawa langkah-langkah yang sama ke Steve Trucking.

Duduk, Diam, Modelkan

Awal: spreadsheet mentah. Saya menampilkan beberapa anjing di layar, lalu peserta di ruangan menambahkan anjing mereka. Dalam beberapa menit kita punya satu daftar besar: anjingnya, tahun lahirnya, siapa pemiliknya, di mana pemiliknya tinggal, rasnya, siapa peternaknya, dan trik yang dikuasainya.

Anjing	Lahir	Pemilik	Kode Pos	Kota	Ras	Peternak	Trik
Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge	Duduk, Diam, Salaman
Milo	2019	Marcus	80202	Denver	Poodle	Golden Meadow	Duduk, Berguling
Max	2022	Ana	64105	Kansas City	Campuran		Duduk, Pura-pura Mati
Luna	2020	Kenji	98101	Seattle	Husky	Cascade	Duduk, Diam, Berputar
Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge	Duduk
Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws	Salaman, Berputar

Ini berfungsi. Setiap spreadsheet berfungsi di hari pertama. Tetapi lihat apa yang sudah salah. Bagaimana saya menemukan semua anjing yang bisa Salaman? Kode pos Ana ada di dua baris, begitu juga milik Marcus: apa yang terjadi jika seseorang memperbarui yang satu tetapi tidak yang lain? Maple Ridge muncul dua kali, begitu juga Kansas City. Dan Max berasal dari penampungan hewan, jadi sama sekali tidak punya peternak.

Langkah 1: bentuk normal pertama. Dua aturan. Setiap bidang menyimpan satu nilai saja, jadi daftar trik yang dipisahkan koma harus dihapus. Dan setiap baris butuh sesuatu yang mengidentifikasinya secara unik. Bukan nama anjingnya; ada banyak sekali anjing bernama Max. Sebuah ID: ID yang dibuat otomatis atau GUID. Trik-triknya dikeluarkan ke baris-barisnya sendiri, satu baris untuk setiap anjing dan setiap trik. Dan begitu sebuah trik punya barisnya sendiri, ada ruang untuk hal yang tidak pernah bisa kita sampaikan dalam daftar berkoma: seberapa sulit trik itu, seberapa baik anjing ini melakukannya, dan kapan ia mempelajarinya.

Anjing (diidentifikasi oleh ID Anjing)

ID Anjing	Nama	Lahir	Pemilik	Kode Pos	Kota	Ras	Peternak
D-001	Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge
D-002	Milo	2019	Marcus	80202	Denver	Poodle	Golden Meadow
D-003	Max	2022	Ana	64105	Kansas City	Campuran
D-004	Luna	2020	Kenji	98101	Seattle	Husky	Cascade
D-005	Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge
D-006	Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws

Trik Anjing (diidentifikasi oleh ID Anjing + Trik)

ID Anjing	Trik	Kesulitan	Tingkat Keterampilan	Dipelajari
D-001	Duduk	Mudah	Ahli	2017-11
D-001	Diam	Mudah	Ahli	2018-01
D-001	Salaman	Sedang	Baik	2018-06
D-002	Duduk	Mudah	Ahli	2020-02
D-002	Berguling	Sulit	Belajar	2023-05
D-003	Duduk	Mudah	Baik	2022-06
D-003	Pura-pura Mati	Sulit	Belajar	2024-03
D-004	Duduk	Mudah	Ahli	2020-11
D-004	Diam	Mudah	Baik	2021-01
D-004	Berputar	Sedang	Ahli	2021-06
D-005	Duduk	Mudah	Belajar	2025-02
D-006	Salaman	Sedang	Ahli	2015-06
D-006	Berputar	Sedang	Belajar	2025-04

Sekarang “semua anjing yang bisa Salaman” menjadi pertanyaan sederhana. Tetapi perhatikan apa yang mengidentifikasi Trik Anjing: bukan satu hal, melainkan dua hal sekaligus, anjingnya dan triknya. Ingat itu baik-baik.

Langkah 2: bentuk normal kedua. Bentuk normal kedua hanya berlaku ketika sebuah baris diidentifikasi oleh kombinasi, dan Trik Anjing memang begitu. Jadi saya bertanya pada setiap kolom: apakah ia menggambarkan keseluruhan kombinasinya, atau hanya sebagiannya? Tingkat Keterampilan menggambarkan anjing ini melakukan trik ini: Bella ahli dalam Duduk, Rocky masih belajar. Dipelajari, sama saja. Tetapi Kesulitan? Duduk itu mudah, anjing mana pun yang melakukannya. Kesulitan menggambarkan triknya, hanya sebagian dari kuncinya, dan itulah sebabnya “Mudah” diulang di setiap baris Duduk. Jadi trik mendapat tabelnya sendiri, dan yang tersisa adalah pasangannya.

Trik

ID Trik	Trik	Kesulitan
T-01	Duduk	Mudah
T-02	Diam	Mudah
T-03	Salaman	Sedang
T-04	Berguling	Sulit
T-05	Pura-pura Mati	Sulit
T-06	Berputar	Sedang

Trik Anjing (ID Anjing + ID Trik)

ID Anjing	ID Trik	Tingkat Keterampilan	Dipelajari
D-001	T-01	Ahli	2017-11
D-001	T-02	Ahli	2018-01
D-001	T-03	Baik	2018-06
D-002	T-01	Ahli	2020-02
D-002	T-04	Belajar	2023-05
D-003	T-01	Baik	2022-06
D-003	T-05	Belajar	2024-03
D-004	T-01	Ahli	2020-11
D-004	T-02	Baik	2021-01
D-004	T-06	Ahli	2021-06
D-005	T-01	Belajar	2025-02
D-006	T-03	Ahli	2015-06
D-006	T-06	Belajar	2025-04

Tabel Trik Anjing itu adalah tabel yang kita temukan di modul 2, dan dalam pemodelan data ia punya nama: penghubung (junction), atau sebutan saya, objek penghubung logis. Seekor anjing menguasai banyak trik; sebuah trik dikuasai banyak anjing. Penghubung itu berada di antara keduanya, dan ia bukan sekadar pipa kosong: ia menyimpan fakta-fakta milik hubungan itu sendiri, yaitu tingkat keterampilan dan tanggalnya. Kita akan bertemu dengannya lagi di modul 6, dan di bab 3 kita akan melihat bahwa Salesforce memakai istilah “junction object” secara lebih sempit: Junction Object Salesforce adalah objek kustom dengan dua hubungan master-detail (bab 3, modul 7).

Langkah 3: bentuk normal ketiga. Sekarang kembali ke tabel Anjing. Semua yang ada di dalamnya diidentifikasi oleh ID Anjing, jadi bentuk normal kedua tidak punya apa-apa untuk dikatakan. Bentuk normal ketiga mengajukan pertanyaan yang berbeda: apakah fakta ini menggambarkan anjingnya, atau sesuatu lain yang berhubungan dengan anjing itu? Ras adalah hal tersendiri: Labrador tetap Labrador, anjing mana pun itu, dan fakta tentangnya, seperti ukurannya, milik rasnya, bukan milik Bella. Kode pos dan kota menggambarkan pemiliknya, bukan anjingnya: di situlah Ana tinggal, anjing mana pun miliknya yang sedang kita lihat. Detail peternak menggambarkan peternaknya. Masing-masing adalah fakta tentang fakta lain, jadi masing-masing pindah ke tabelnya sendiri, dan anjing menunjuk ke sana dengan foreign key:

• Anjing: ID Anjing, Nama, Lahir, ID Pemilik, ID Ras, ID Peternak
• Pemilik: ID Pemilik, Nama, Kode Pos, Kota
• Ras: ID Ras, Ras, Ukuran
• Peternak: ID Peternak, Nama, Kota
• Trik dan Trik Anjing, dari langkah 2

Sekarang Ana disimpan sekali, dengan kedua anjingnya menunjuk kepadanya. Maple Ridge disimpan sekali, dan tabel Ras memberi kita tempat untuk fakta tentang setiap ras, seperti ukurannya, yang di spreadsheet tidak punya tempat. Foreign key boleh kosong: Max tidak punya ID Peternak, dan itu jawaban yang jujur, bukan celah. Lalu saya melempar pertanyaan jebakan ke peserta: kapan pemilik mendapatkan anjingnya, di mana tanggal itu diletakkan? Di anjingnya. Dalam model ini seekor anjing hanya punya satu pemilik pada satu waktu, jadi tanggal itu menggambarkan hubungan anjing dengan pemiliknya.

Anda bisa melangkah satu tahap lagi dan memisahkan kota dari kode pos; buku teks melakukannya. Dalam praktiknya, sebuah alamat tetap utuh, dan lagi pula Kansas City terletak di dua negara bagian, pengingat yang bagus bahwa dunia nyata tidak membaca buku teks kita.

Itulah alurnya: sebuah spreadsheet, lalu tiga pertanyaan, dan setiap fakta berakhir di satu tempat. Mundur sejenak dan lihat apa yang telah kita bangun. Satu daftar yang berantakan menjadi enam tabel, masing-masing menggambarkan satu hal, dihubungkan oleh kunci:

Click to enlarge

Tidak ada yang butuh satu kata Salesforce pun untuk mengikutinya. Hanya anjing-anjing itu, orang-orang di sekitarnya, dan apa yang mereka kuasai.

Sekarang Mari Terapkan di Steve Trucking

Anjing-anjing itu membuat langkah-langkahnya mudah dilihat. Bisnis nyata membuatnya penting, karena kesalahan yang sama menghabiskan uang sungguhan dalam skala besar. Jadi mari kita bawa tiga pertanyaan yang sama ke Steve Trucking. Bayangkan perusahaan itu menyimpan pengirimannya seperti ini:

Pengiriman	Mitra Ritel	Pusat Distribusi	Kota DC	Kru	Truk
1001	Keystone	Keystone Phoenix DC	Phoenix	Kru 12	117
1002	Keystone	Keystone Phoenix DC	Phoenix	Kru 8	122
1003	Keystone	Keystone Phoenix DC	Phoenix	Kru 12	117

Sekilas tidak ada yang rumit di sini. Tetapi lihat pusat distribusinya. Kita mengulang “Keystone Phoenix DC, Phoenix” di setiap pengiriman yang berangkat dari sana: Steve Trucking melakukan sekitar 3.300 pengiriman sehari dari sembilan DC, jadi beberapa ratus sehari dari masing-masing DC. Apa yang terjadi jika DC itu pindah? Berapa banyak rekaman yang kita ubah, dan apa yang terjadi jika satu terlewat? Sekarang data mengatakan DC itu berada di dua kota sekaligus. Itulah anomali pembaruan. Bagaimana jika kita ingin menyiapkan DC baru sebelum pengiriman pertamanya? Bagaimana jika kita menghapus pengiriman terakhir dari sebuah DC: apakah kita baru saja menghapus satu-satunya tempat kita menyimpan informasi tentang DC itu?

Ini gejala-gejala berbeda dari masalah yang sama: kita mencampur fakta tentang hal-hal yang berbeda. Fakta pusat distribusi milik pusat distribusi. Fakta pengiriman milik pengiriman. Fakta kru milik kru. Itulah normalisasi dalam istilah praktis.

Bentuk Normal Pertama: Jangan Menyembunyikan Struktur Berulang

Mari mulai dengan Bentuk Normal Pertama, atau 1NF, tempat orang kadang membuat normalisasi lebih sulit dari yang seharusnya.

Misalkan sebuah pengiriman punya bidang bernama Item: “Kulkas, kit pembuat es, angkut barang lama.” Kita memasukkan tiga informasi ke satu bidang. Kelihatannya praktis, sampai seseorang bertanya, “Berapa kali kita mengangkut barang lama bulan lalu?” Atau bayangkan bidang bernama Item 1, Item 2, dan Item 3. Itu berfungsi, sampai ada pengiriman dengan empat item. Masalahnya bukan kita memilih jumlah bidang Item yang salah. Masalahnya kita tidak mengenali struktur yang berulang. Sebuah pengiriman bisa punya beberapa item. Itu data yang seharusnya kita modelkan: Item Pengiriman yang kita temukan di modul 2.

Click to enlarge

Pelajaran praktis dari 1NF: jangan menyembunyikan struktur berulang di dalam bidang. Jika bisnis memberi tahu Anda bahwa sesuatu bisa terjadi berkali-kali, dengarkan. Mungkin ada entitas lain yang sedang berusaha keluar.

Anda akan melihat ini di org nyata setiap saat. Seseorang butuh deskripsi dalam beberapa bahasa, jadi mereka membuat bidang bernama Description_English, lalu Description_French, lalu Description_German. Atau sebuah persetujuan butuh beberapa orang, jadi muncullah Penyetuju 1, Penyetuju 2, Penyetuju 3. Ketika saya menemukan itu dalam sebuah review, tangannya saya tepuk: perbaiki model datamu. Satu atau dua, mungkin, jika bisnis memang hanya pernah punya satu atau dua. Lebih dari itu seharusnya menjadi objek anak: Terjemahan dengan bahasanya, Langkah Persetujuan dengan penyetujunya. Bahasa berikutnya, atau penyetuju keempat, menjadi rekaman baru, bukan bidang baru plus deployment.

Bentuk Normal Kedua: Gambarkan Keseluruhannya

Bentuk Normal Kedua, atau 2NF, penting ketika sebuah rekaman diidentifikasi oleh kombinasi beberapa hal. Ambil Item Pengiriman. Ia punya record ID sendiri, tetapi masing-masing unik berdasarkan Pengiriman + Produk. Misalkan kita menyimpan pengirimannya, produknya, jumlahnya, dan deskripsi produknya.

Jumlah masuk akal di sini: ia menggambarkan produk ini pada pengiriman ini. Tetapi deskripsi produk tidak menggambarkan kombinasinya; ia menggambarkan produknya. Taruh di setiap Item Pengiriman, dan kita mengulangnya setiap kali model kulkas itu berangkat di truk lain. Itulah petunjuk bahwa fakta tersebut seharusnya berada di tempat lain.

Jadi pertanyaan 2NF adalah: apakah atribut ini menggambarkan keseluruhan hal yang saya identifikasi, atau hanya sebagiannya? Jika hanya menggambarkan produk, ia ikut ke Produk. Jika menggambarkan posisi produk pada pengiriman tertentu ini (jumlahnya, apakah dipasang), ia milik Item Pengiriman. Banyak admin tidak akan pernah secara sadar berkata, “Sekarang saya sedang menerapkan Bentuk Normal Kedua.” Tidak apa-apa. Saya jauh lebih peduli Anda belajar bertanya: apa yang sebenarnya digambarkan oleh fakta ini?

Bentuk Normal Ketiga: Jangan Menyimpan Fakta tentang Fakta Lain

Sekarang yang paling saya pedulikan untuk pemodelan sehari-hari: Bentuk Normal Ketiga, atau 3NF.

Setiap pusat distribusi punya manajer di pihak Mitra Ritel, seseorang yang memakai portal mitra. Misalkan kita menaruh nama manajer DC langsung di setiap pengiriman. Apa yang terjadi ketika DC itu mendapat manajer baru? Kita memperbarui setiap pengiriman dari DC itu. Itu gejala yang sama lagi: kita mengulang fakta yang seharusnya berada di tempat lain. Pengiriman berangkat dari sebuah DC; DC punya manajer. Itu dua hubungan, dan nama manajer seharusnya berada di DC.

Versi klasik di buku teks adalah alamat: kode pos, kota, dan negara bagian disimpan bersama di setiap rekaman, padahal kota dan negara bagian biasanya sudah bisa diketahui dari kode posnya. Bentuknya sama, pertanyaannya sama.

Click to enlarge

Pertanyaan praktis 3NF adalah: apakah fakta ini menggambarkan hal ini, atau sesuatu lain yang berhubungan dengan hal ini? Saya ingin Anda terus-menerus menanyakannya.

Sekarang mundur sejenak, seperti yang kita lakukan dengan anjing-anjing tadi. Tabel pengiriman yang kita mulai telah menjadi lima hal, masing-masing menyimpan faktanya sendiri: Item Pengiriman keluar di bentuk normal pertama, Produk di bentuk kedua, dan kota serta manajer Pusat Distribusi pindah ke Pusat Distribusi di bentuk ketiga.

Click to enlarge

Tiga pertanyaan yang sama, hasil yang sama: setiap fakta di satu tempat.

Cara Sederhana Memikirkan 1NF, 2NF, dan 3NF

Anda bisa menghabiskan satu kursus database penuh untuk normalisasi. Kita tidak akan melakukannya. Untuk kursus ini, saya ingin Anda punya pemahaman praktis seorang arsitek:

• 1NF: apakah saya menyembunyikan beberapa nilai atau struktur berulang di dalam sebuah bidang atau rekaman?
• 2NF: apakah fakta ini menggambarkan keseluruhan hal yang saya identifikasi?
• 3NF: apakah fakta ini benar-benar menggambarkan entitas ini, atau sesuatu yang berhubungan dengannya?

Itu bukan definisi untuk buku teks database. Itu pertanyaan yang benar-benar bisa saya pakai saat sedang merancang.

Ya, normalisasi masih berlanjut: Boyce-Codd Normal Form (BCNF) memperketat aturan di sekitar 3NF untuk model dengan kunci yang lebih rumit, dan ada Bentuk Normal Keempat, Kelima, bahkan Keenam. Bentuk-bentuk itu menangani jenis pengulangan yang lebih jarang, yang lebih banyak muncul dari struktur kunci yang tidak biasa daripada dari rekaman bisnis sehari-hari. Banyak teori, dan menurut pengalaman saya tidak sepadan dengan pusingnya untuk jenis sistem yang kita bangun di Salesforce. Dalam sistem bisnis, tekanannya biasanya justru ke arah sebaliknya: kita jauh lebih mungkin mundur dari bentuk normal ketiga, demi pengguna, pelaporan, dan kinerja, daripada melampauinya. Itu modul berikutnya. Ketahuilah bahwa bentuk-bentuk lanjutan itu ada, tetapi untuk sebagian besar pekerjaan kita, 1NF hingga 3NF memberi kita alat berpikir yang kita butuhkan.

Rancang untuk Bentuk Normal Ketiga

Inilah posisi saya. Ketika saya berusaha memahami sebuah bisnis dan merancang model logisnya, saya ingin memulai dengan bersih: fakta pengiriman bersama pengiriman, fakta pusat distribusi bersama DC, fakta truk bersama truk, konsep yang berulang dimodelkan sebagai konsep. Saya tidak ingin sebuah fakta bisnis disalin ke seluruh model hanya karena mungkin membuat sebuah layar atau laporan lebih mudah. Belum.

Tetapi normalisasi bukan agama. Tujuannya bukan model yang paling murni secara akademis. Saya pernah melihat arsitek begitu terpaku pada kemurnian sampai modelnya menyiksa bagi semua orang yang harus memakainya. Kita tidak sedang berusaha memenangkan lomba normalisasi; kita sedang membangun sebuah sistem, dan sistem itu punya pengguna, laporan, integrasi, kebutuhan kinerja, skala, dan, semakin sering, AI yang membaca datanya. Semua itu mungkin menginginkan data dalam bentuk yang berbeda.

Jadi titik awal saya adalah rancang hingga Bentuk Normal Ketiga jika memungkinkan, lalu mundur sedikit jika perlu: pahami dulu di mana setiap fakta seharusnya berada. Lalu, jika kita akan menyimpang darinya, saya ingin tahu alasannya. Jika jawabannya “karena saya tidak tahu harus menaruh bidang itu di mana lagi,” itu tidak cukup baik. Jika jawabannya “kami sengaja menyalin nilai ini karena membuat scorecard mitra menjadi sederhana, dan kami punya cara yang andal untuk menjaganya tetap sinkron,” barulah kita sedang melakukan percakapan arsitektur.

Yang Diputuskan Arsitek di Sini

Saat menormalisasi model logis, saya mencari:

• Nilai atau struktur berulang yang seharusnya dimodelkan secara terpisah.
• Atribut yang menggambarkan entitas yang berbeda dari entitas tempat atribut itu disimpan.
• Fakta yang diduplikasi tanpa perlu di banyak rekaman, dan ketergantungan yang membuatnya menjadi tidak konsisten.
• Konsep bisnis yang tersembunyi di dalam bidang.
• Model yang bersih yang mewakili kebenaran sebelum ada kompromi implementasi apa pun.

Bukan karena setiap sistem fisik harus tetap ternormalisasi sempurna. Justru sebaliknya. Di modul berikutnya kita akan sengaja menyimpang dari model yang bersih, demi pengguna, pelaporan, skala, analitik, dan AI, dan kita akan melakukannya dengan tahu persis apa yang kita pertukarkan.