Skip to content
jsonforge.app
Kembali ke blog
Panduan8 menit baca

Bekerja dengan JSON Bersarang: Flattening, Querying, dan Transformasi Data

JSON bersarang secara alami — object di dalam object, array di dalam object, object di dalam array — karena begitulah program memodelkan data. Spreadsheet, berkas CSV, dan tabel SQL tidak bersarang sama sekali; mereka ketat dua dimensi, baris dan kolom. Celah antara dua dunia itulah tempat 'flattening' muncul, dan mengetahui kapan melakukan flatten dan kapan membiarkan struktur apa adanya adalah bagian terbesar dari apa yang membuat JSON bersarang menjadi mudah dikelola.

Mengapa JSON yang bersarang dalam menolak spreadsheet dan SQL

Object JSON dengan tiga level nesting dan array terkubur di dalamnya tidak punya pemetaan baris/kolom yang jelas — field mana menjadi kolom, dan apa yang terjadi pada field yang berulang per item array? Menempelkan JSON bersarang ke konverter 'JSON to CSV' naif atau impor JSON Excel entah menjatuhkan field bersarang sepenuhnya atau menumpukkannya ke satu sel sebagai blob stringified — dan kedua hasil itu membuang persis struktur yang ingin Anda filter, urutkan, atau query.

Ini bukan begitu-begitu saja kegagalan tooling, melainkan ketidakcocokan representasi yang nyata: JSON bersarang mengodekan pohon, sedangkan spreadsheet atau tabel SQL mengodekan daftar record yang datar. Berpindah dari satu ke yang lain membutuhkan keputusan eksplisit tentang cara menangani ketidakcocokan itu, bukan sekadar konversi format.

Apa arti flattening sebenarnya

Flattening mentransformasikan struktur bersarang menjadi object berlevel tunggal di mana setiap path bersarang menjadi satu key, umumnya disambung dengan titik (`user.address.city`) atau ditulis dalam notasi kurung siku (`user[address][city]`). Item array mendapat indeks dalam path (`roles.0`, `roles.1`), mengubah daftar menjadi sekumpulan key yang bisa dialamati satu per satu. Hasilnya sama sekali tak bersarang — setiap nilai adalah string, number, atau boolean polos, dan setiap key secara unik mengidentifikasi tepat satu nilai leaf dalam dokumen asli.

Properti itu — satu key per nilai leaf, tanpa nesting — persis yang dibutuhkan kolom spreadsheet, baris SQL, atau key/value store sederhana.

Contoh pengerjaan

Ambil record pengguna bersarang yang khas dengan object address dan array string role.

Object sumber yang bersarang.
json
{
  "user": {
    "id": 42,
    "name": "Ada Lovelace",
    "address": {
      "city": "London",
      "postcode": "W1"
    },
    "roles": ["admin", "editor"]
  }
}
Data yang sama di-flatten menjadi peta key/value berlevel tunggal dengan dot-path.
json
{
  "user.id": 42,
  "user.name": "Ada Lovelace",
  "user.address.city": "London",
  "user.address.postcode": "W1",
  "user.roles.0": "admin",
  "user.roles.1": "editor"
}

Enam key, nol nesting, dan masing-masing adalah path langsung yang tak ambigu menuju satu nilai asli — sangat mudah dipakai sebagai enam kolom spreadsheet atau enam kolom dalam satu baris SQL.

Kapan melakukan flatten vs. mempertahankan nesting

Lakukan flatten ketika tujuannya benar-benar tabular — ekspor CSV, spreadsheet, satu baris tabel SQL, alat analitik yang hanya paham kolom datar — dan ketika array berupa daftar skalar yang pendek (seperti `roles` di atas) di mana key berindeks per item adalah trade-off yang wajar.

Pertahankan nesting, atau restrukturisasi alih-alih flatten, ketika array berisi object utuh yang jumlahnya bervariasi per record — array `orders` di mana tiap pengguna punya jumlah order berbeda, masing-masing dengan beberapa field sendiri. Melakukan flatten di tempat entah menghasilkan kumpulan kolom yang berbeda dan tak rata per record (`orders.0.total`, `orders.1.total`, ... `orders.14.total` untuk pelanggan terbesar Anda) atau menyerah dan melipat seluruh array menjadi satu sel JSON stringified — yang mengalahkan tujuan flatten itu sendiri. Langkah yang lebih baik untuk array-of-object adalah normalisasi relasional klasik: keluarkan array menjadi tabel/sheet tersendiri dengan foreign key kembali ke record induk, alih-alih memaksakannya menjadi kolom pada baris induk. Persis inilah yang dilakukan alat JSON to Table milik JsonForge secara otomatis — ia me-flatten field skalar menjadi kolom tabel dan memecah array of object menjadi tabel-tabel terkait tersendiri alih-alih merusaknya menjadi kolom berindeks angka.

Akses berbasis path: query tanpa me-flatten semuanya

Kadang Anda tidak perlu me-flatten seluruh dokumen — Anda hanya butuh satu nilai dari struktur yang bersarang dalam. Notasi dot-path (`user.address.city`) atau ekspresi gaya JSONPath (`$.user.address.city`, `$.roles[0]`) memungkinkan Anda mengalamati satu nilai bersarang secara langsung — ide dasar yang sama dengan flatten, diterapkan pada satu pencarian alih-alih seluruh dokumen. Inilah yang menggerakkan `lodash.get(obj, 'user.address.city')`, interpolasi variabel di kebanyakan template engine, dan alat query JSON pada umumnya.

Dalam praktiknya kedua teknik ini saling melengkapi: alat JSON Flatten milik JsonForge menerapkan transformasi dot-path ini pada seluruh dokumen sekaligus, mengubah setiap nilai bersarang menjadi key datar yang bisa dialamati — berguna setiap kali tujuannya spreadsheet, key/value store sederhana, atau alat apa pun yang tak bisa menelusuri struktur bersarang secara native.

FAQ

Apa bedanya flattening dengan sekadar men-stringify field bersarang?
Flattening mengubah setiap nilai bersarang menjadi key skalar level-atasnya sendiri, sehingga setiap nilai tetap bisa di-query, diurutkan, dan difilter secara independen. Men-stringify field bersarang melipatnya menjadi satu blob teks opaque — Anda bisa menampilkannya, tetapi tak bisa memfilter nilai di dalamnya atau mengurutkannya tanpa mem-parse ulang stringnya lebih dulu. Flattening mempertahankan kemampuan query; stringify hanya menunda masalahnya.
Bagaimana array direpresentasikan saat me-flatten JSON?
Konvensi standarnya adalah menambahkan indeks array ke path, jadi `roles: ["admin", "editor"]` menjadi `roles.0: "admin"` dan `roles.1: "editor"`. Ini bekerja bersih untuk daftar skalar yang pendek dan agak tetap, tetapi menghasilkan kumpulan key yang tak rata dan terus bertumbuh untuk array yang panjangnya sangat bervariasi antar-record — dalam kasus itu tabel terkait terpisah biasanya lebih cocok daripada key indeks yang di-flatten.
Bisakah object JSON yang di-flatten dikembalikan ke bentuk bersarang aslinya?
Bisa — 'unflattening' membalik prosesnya dengan memecah setiap key dot-path kembali menjadi bagian-bagiannya dan membangun ulang object dan array bersarang darinya, selama konvensi pemisahnya diterapkan konsisten dan tidak ada key asli yang kebetulan mengandung titik literal.
Apakah notasi titik adalah satu-satunya cara merepresentasikan key yang di-flatten?
Tidak. Notasi titik (`user.address.city`) adalah yang paling umum karena mencerminkan cara Anda mengakses nilainya di JavaScript atau Python, tetapi notasi kurung siku (`user[address][city]`) dan key bersambung underscore (`user_address_city`) juga dipakai, terutama oleh alat yang menargetkan lingkungan di mana titik pada nama kolom merepotkan (sebagian dialek SQL, alat spreadsheet tertentu). Konvensinya kurang penting daripada menerapkannya konsisten di seluruh dokumen.

Coba alat ini

Artikel terkait