Dari Google Sheet ke skema relasional: rencana pemodelan langkah demi langkah

Mengapa spreadsheet berantakan saat dijadikan database

Spreadsheet bagus untuk daftar kecil. Anda bisa mengubah kolom sesuka hati, menambahkan catatan di mana saja, dan memperbaiki masalah dengan melihatnya langsung. Kebebasan itu mulai runtuh saat file menjadi sumber kebenaran bersama.

Seiring data tumbuh, masalah yang sama muncul berulang kali. Anda melihat duplikasi karena tidak ada satu tempat untuk menyimpan pelanggan atau produk. Anda mendapatkan nilai yang bertentangan karena dua baris berbeda tentang hal yang sama, seperti nomor telepon. Penyaringan dan pelaporan menjadi menyebalkan karena beberapa kolom menyembunyikan daftar ("Tags", "Products", "Attendees") atau mencampur format ("$1,200", "1200", "1.2k").

Berpindah dari Google Sheet ke skema relasional adalah soal keselamatan. Database memaksa struktur yang lebih jelas sehingga Anda bisa query, validasi, dan memperbarui data tanpa menciptakan kontradiksi baru.

Model mental yang berguna: satu baris harus mewakili satu hal nyata. Jika satu baris mewakili deal, pelanggan, dan daftar produk, memperbarui salah satu nanti akan menyakitkan.

Tes cepat: apakah satu baris kadang butuh dua nilai untuk field yang sama?

• Satu order memiliki banyak produk
• Satu proyek memiliki banyak anggota tim
• Satu pelanggan memiliki banyak alamat

Jika jawabannya ya, ini bukan masalah “baris lebar”. Ini masalah “tabel terpisah”. Setelah Anda memodelkannya dengan bersih, Anda bisa membangun formulir dan validasi di atasnya daripada mengandalkan edit manual yang rapuh.

Mulai dengan mendefinisikan apa arti sheet itu sebenarnya

Spreadsheet bisa terlihat rapi tapi tetap berarti hal berbeda bagi orang berbeda. Sebelum mengubah Google Sheet menjadi skema relasional, sepakati apa yang dilacak oleh sheet itu.

Mulai dari hasil yang diinginkan, bukan kolom. Keputusan apa yang harus didukung data: laporan pendapatan mingguan, daftar tiket yang terlambat, alur kerja yang menugaskan tindak lanjut, atau pencarian cepat selama panggilan pelanggan? Jika Anda tidak bisa menyebutkan keputusan, field itu sering kali tidak perlu dimasukkan ke database.

Selanjutnya, ambil kata benda yang tersembunyi di header dan catatan. Ini biasanya menjadi tabel masa depan: customers, orders, products, invoices, tickets, agents, locations. Jika sebuah kolom mencampur dua kata benda (seperti “Customer + Company”), Anda menyimpan banyak hal di satu tempat.

Sepakati definisi sejak awal

Perbedaan kecil dalam arti berubah jadi pembersihan besar nanti. Jelaskan dasar-dasarnya:

• Apa yang dihitung sebagai “order” (penawaran, pembelian yang dibayar, atau keduanya)?
• Apa itu “customer” (individu, perusahaan, atau keduanya)?
• Bisakah satu order memiliki banyak produk?
• Bisakah satu email dimiliki banyak pelanggan?
• Apa yang dimaksud dengan “status” (keadaan saat ini atau riwayat)?

Contoh: jika sheet Anda memiliki satu baris per “Order” tetapi sel “Products” berisi daftar yang dipisah koma, putuskan apakah baris itu mewakili checkout, pengiriman, atau faktur. Setiap pilihan mengarah ke skema berbeda.

Bekukan salinan sheet asli sebagai read-only. Anda akan menggunakannya untuk memvalidasi bahwa tabel baru masih menjawab pertanyaan yang sama.

Bersihkan sheet agar struktur terlihat

Sebelum mengonversi Google Sheet ke skema relasional, buat sheet terlihat seperti data, bukan laporan. Database butuh baris dan kolom yang konsisten. Tata letak dekoratif menyembunyikan pola yang perlu Anda modelkan.

Hapus trik tata letak seperti sel yang digabung, beberapa baris header, dan subtotal di dalam rentang data. Pertahankan satu baris header lalu baris-baris record saja. Jika Anda butuh total, letakkan di tab ringkasan terpisah agar tidak tercampur dengan record sebenarnya.

Lalu buat format konsisten di setiap kolom. Database tidak bisa menebak bahwa “1/2/24”, “2024-02-01”, dan “Feb 1” adalah tanggal yang sama. Hal yang sama berlaku untuk nomor telepon, mata uang, dan nama. Pilih satu format dan gunakan di mana-mana, meskipun terasa ketat.

Langkah pembersihan singkat yang biasanya bermanfaat:

• Pastikan setiap baris mewakili satu hal (satu order, satu pelanggan, satu tiket).
• Hapus baris dan kolom spacer kosong.
• Ganti “N/A”, “-”, dan string kosong dengan satu aturan yang akan Anda pertahankan.
• Tandai kolom mana yang dihitung vs diketik oleh orang.

Terakhir, tandai setiap sel yang berisi banyak nilai, seperti “red, blue, green” di satu kolom. Jangan memutuskan skemanya dulu. Tandai saja kolom tersebut agar Anda ingat nanti akan menjadi baris terpisah.

Identifikasi grup berulang dan field yang menyembunyikan daftar

Tanda peringatan terbesar dalam pemodelan data spreadsheet adalah repetisi. Sheet sering memampatkan “lebih dari satu hal” ke satu baris dengan mengulang kolom atau memasukkan banyak nilai dalam satu sel. Itu bekerja untuk pelacakan cepat, lalu rusak ketika Anda butuh penyaringan, pelaporan, atau pembaruan konsisten.

Pola yang biasanya berarti “ini harus tabel lain”

Pindai bentuk-bentuk ini:

• Kolom bernomor seperti Item 1, Item 2, Item 3 atau Phone 1, Phone 2.
• Blok berulang seperti field alamat yang diduplikasi untuk “Home” dan “Work”.
• Sel dengan koma, pemecah baris, atau “dan” yang menggabungkan nilai (misal, “Mouse, Keyboard, Monitor”).
• Satu kolom yang mencampur dua konsep, seperti “Approved 2025-01-10” atau “Alex (Manager)”.
• Baris yang mewakili dua level sekaligus, seperti baris Order yang juga mencoba menyimpan semua Order Items.

Contoh: jika tracker penjualan Anda menggunakan Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2, Anda akan menemui batas. Beberapa order punya 1 item, beberapa punya 8. Sheet akan berkembang melebar selamanya atau mulai kehilangan data. Dalam model relasional, “Orders” menjadi satu tabel, dan “Order Items” menjadi tabel lain dengan satu baris per produk di order.

Untuk “daftar dalam sel”, perlakukan setiap nilai sebagai record sendiri. Sel yang berisi “Email, SMS” biasanya berarti Anda butuh tabel terpisah (atau tabel join) untuk melacak channel dengan bersih.

Kolom campuran lebih halus tapi sama berisiko. Pisahkan lebih awal sehingga setiap field menyimpan satu fakta yang jelas.

Buat tabel dari entitas yang Anda temukan

Setelah Anda bisa menamai benda dunia nyata dalam sheet, ubah masing-masing menjadi tabel tersendiri. Spreadsheet Anda berhenti menjadi satu grid besar dan menjadi serangkaian daftar kecil yang bertujuan.

Jika satu baris mencampur detail tentang dua hal berbeda, kemungkinan perlu dua tabel. Baris tracker penjualan mungkin mencakup info pelanggan (nama, telepon), info order (tanggal, status), dan info produk (SKU, harga). Pelanggan tidak berubah setiap kali order berubah, dan produk tidak tergantung pada satu order. Memisahkan mereka mencegah edit ganda dan nilai yang tidak cocok.

Sebelum finalisasi, tulis satu kalimat tujuan untuk setiap tabel. Jika Anda tidak bisa menjelaskan apa yang direpresentasikan tabel tanpa mengatakan “dan juga”, biasanya tabel itu terlalu luas.

Beberapa aturan praktis:

• Simpan atribut yang menggambarkan hal yang sama dan berbagi siklus hidup bersama (nama pelanggan dan email pelanggan).
• Pindahkan apa pun yang bisa muncul berulang kali ke tabel sendiri (banyak order items, banyak alamat).
• Jika sebuah sel berisi daftar (dipisah koma, kolom berulang), itu tabel terpisah.
• Jika dua set field berubah karena alasan berbeda, pisahkan (status order vs info kontak pelanggan).

Kemudian beri nama kolom dengan jelas dan konsisten. Utamakan kata benda sederhana dan hindari label samar seperti “Info” atau “Details”.

Pilih kunci yang stabil seiring waktu

Pilih primary key untuk setiap tabel sejak awal. Kunci yang bagus itu membosankan: tidak pernah berubah, selalu ada, dan mengidentifikasi satu baris satu-satunya.

Natural key (nilai dunia nyata) bisa bekerja, tapi hanya jika benar-benar stabil. SKU seringkali merupakan natural key yang baik karena dimaksudkan permanen. Alamat email terdengar stabil, tetapi orang mengganti email, berbagi inbox, dan membuat duplikat seperti “john@” dan “john.work@”. Nama, nomor telepon, dan alamat berubah dan tidak dijamin unik.

Default yang aman adalah ID yang di-generate otomatis (misal customer_id, order_id). Simpan pengenal natural sebagai field biasa, dan tambahkan aturan keunikan saat sesuai dengan aturan bisnis Anda. Jika email berubah, customer_id tetap sama dan order terkait tetap menunjuk ke pelanggan yang benar.

Aturan kunci sederhana:

• Gunakan auto ID ketika pengenal dunia nyata mungkin berubah, hilang, atau digunakan ulang.
• Gunakan natural key hanya ketika Anda mengendalikannya dan dirancang untuk permanen (misalnya SKU).
• Tandai field sebagai unik hanya ketika duplikat benar-benar salah.
• Izinkan NULL hanya ketika “tidak diketahui” adalah keadaan valid; jika tidak, minta nilai.
• Tulis apa arti “unik” (unik per tabel, per perusahaan, atau per periode waktu).

Contoh: di tabel Contacts, gunakan contact_id sebagai primary key. Pertahankan email sebagai unik hanya jika aturan Anda adalah satu kontak = satu email. Biarkan phone kosong karena tidak semua orang memilikinya.

Petakan relasi tanpa menebak

Kebanyakan kesalahan besar datang dari menebak bagaimana sesuatu saling terkait. Gunakan aturan sederhana: jika satu baris “memiliki” banyak hal, itu one-to-many. Letakkan foreign key di sisi “banyak”.

Contoh: satu Customer bisa punya banyak Orders. Tabel Orders harus menyimpan customer_id. Jika Anda menyimpan daftar nomor order yang dipisah koma di Customers, duplikasi dan data yang hilang cepat muncul.

Many-to-many adalah jebakan spreadsheet umum. Jika satu Order bisa berisi banyak Product dan satu Product bisa muncul di banyak Order, Anda butuh join table (sering disebut line items). Biasanya mencakup order_id, product_id, plus field seperti quantity dan harga saat pembelian.

One-to-one jarang. Masuk akal ketika data ekstra opsional atau disimpan terpisah demi privasi atau performa (misal User dan UserProfile). Itu jadi tanda bahaya ketika Anda membagi tabel hanya karena sheet punya dua tab.

Riwayat butuh struktur sendiri. Jika nilai bisa berubah seiring waktu (status, harga, alamat), hindari menimpa satu kolom. Simpan perubahan sebagai baris di tabel riwayat sehingga Anda bisa menjawab “apa yang benar pada tanggal itu?”

Normalisasi secukupnya untuk mencegah kontradiksi

Aturan sederhana: simpan satu fakta di satu tempat. Jika nomor telepon pelanggan muncul di lima baris, seseorang akan memperbarui empat dan melewatkan satu.

Normalisasi dalam istilah praktis:

1NF, 2NF, 3NF dalam istilah praktis

First normal form (1NF) berarti setiap sel menyimpan satu nilai. Jika kolom berisi “red, blue, green” atau “SKU1|SKU2|SKU3”, itu daftar tersembunyi. Pecah jadi baris di tabel terkait.

Second normal form (2NF) muncul paling sering di line items. Jika Anda punya OrderItems dengan key (OrderID, ProductID), maka field seperti CustomerName tidak pantas ada di sana. Mereka bergantung pada order, bukan produk.

Third normal form (3NF) berarti field non-key tidak seharusnya bergantung pada field non-key lain. Contoh: jika Anda menyimpan ZipCode dan City, dan City ditentukan oleh ZipCode, Anda berisiko mismatch.

Cek singkat:

• Bisakah nilai yang sama diedit di lebih dari satu tempat?
• Apakah satu perubahan memaksa Anda memperbarui banyak baris lain?
• Apakah Anda menyimpan label yang bisa diturunkan dari sebuah ID?
• Apakah total disimpan di samping baris mentah yang menghasilkan total itu?

Kapan denormalisasi boleh dilakukan

Denormalisasi terutama untuk pelaporan yang berat baca, dan lakukan dengan aman: anggap tabel laporan sebagai salinan yang bisa dibangun ulang. Pertahankan tabel ternormalisasi sebagai sumber kebenaran.

Untuk nilai turunan seperti total, saldo, dan status, jangan gandakan kecuali Anda punya aturan jelas untuk menghitung ulang. Pendekatan praktis: simpan transaksi mentah, hitung total dalam query, dan hanya cache total ketika performa memang menuntut.

Perangkap pemodelan umum yang menciptakan pembersihan di masa depan

Sebagian besar masalah “bekerja di sheet” berasal dari makna, bukan alat. Tujuannya adalah agar setiap baris mengatakan satu hal yang jelas, dengan cara yang sama, setiap saat.

Perangkap umum:

• Menggunakan nama sebagai ID. “John Smith” bukan pengenal unik, dan nama berubah. Gunakan ID yang dihasilkan (atau email/telepon terverifikasi), dan perlakukan nama tampilan sebagai label.
• Memasukkan daftar ke satu sel. Terlihat sederhana, tapi merusak pencarian, validasi, dan pelaporan. Daftar seharusnya di tabel terkait.
• Mencampur keadaan saat ini dengan riwayat. Satu kolom Status tidak bisa memberi tahu baik status terbaru maupun bagaimana itu berubah. Jika waktu penting, simpan perubahan status sebagai event dengan cap waktu.
• Membebani satu tabel untuk banyak arti. Sheet Contacts yang mencakup customers, vendors, dan employees biasanya berakhir dengan field yang hanya berlaku untuk beberapa baris. Pisahkan berdasarkan peran, atau jaga tabel Person bersama dan tambahkan tabel spesifik peran.
• Mengabaikan field wajib vs opsional. Jika field kunci bisa kosong, Anda akan mendapatkan baris yang tidak bisa join dengan rapi. Putuskan apa yang wajib dan tegakkan lebih awal.

Jika tabel Orders Anda memiliki kolom seperti Item 1, Item 2, Item 3, Anda sedang melihat repeating group. Rencanakan tabel Orders ditambah OrderItems.

Checklist cepat sebelum Anda mengunci skema

Sebelum mengunci skema, lakukan pemeriksaan akhir untuk kejelasan. Sebagian besar rasa sakit database datang dari jalan pintas kecil yang terasa tidak berbahaya di awal.

Tanyakan apakah setiap tabel menjawab satu pertanyaan sederhana. “Customers” harus berarti pelanggan, bukan pelanggan plus order terbaru mereka plus catatan panggilan. Jika Anda tidak bisa mendeskripsikan tabel dalam satu kalimat pendek, itu mencampur banyak hal.

Pemeriksaan akhir:

• Bisakah Anda menunjuk kolom (atau set kolom) yang mengidentifikasi unik setiap baris, bahkan jika nama berubah?
• Apakah ada sel yang berisi lebih dari satu nilai (tags dipisah koma, banyak email, kolom Item1/Item2)? Jika ya, pisahkan menjadi tabel anak.
• Untuk setiap relasi, apakah disimpan sebagai foreign key yang disengaja? Untuk many-to-many, apakah Anda punya tabel join?
• Apakah field penting punya aturan (wajib ketika data hilang merusak proses, unik ketika duplikasi berbahaya)?
• Bisakah Anda memperbarui satu fakta (alamat pelanggan, harga produk, peran karyawan) di tepat satu tempat?

Tes realita: bayangkan seseorang memasukkan pelanggan yang sama dua kali dengan ejaan sedikit berbeda. Jika skema Anda mempermudah itu, tambahkan kunci yang lebih baik atau aturan keunikan.

Contoh: mengubah sheet tracker penjualan menjadi tabel bersih

Bayangkan tracker penjualan di mana setiap baris adalah deal. Kolomnya: Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (daftar yang dipisah koma), dan Notes (kadang beberapa catatan dalam satu sel).

Satu baris itu menyembunyikan dua repeating group: products (satu deal bisa berisi banyak produk) dan notes (satu deal bisa punya banyak catatan). Di sinilah konversi sering salah, karena daftar dalam sel sulit di-query dan mudah bertentangan.

Model "setelah" yang bersih dan sesuai perilaku kerja:

• Customers (CustomerId, Name, Email)
• Deals (DealId, CustomerId, Amount, Stage, CloseDate)
• Products (ProductId, Name, SKU)
• DealProducts (DealId, ProductId, Quantity, UnitPrice)
• DealNotes (NoteId, DealId, NoteText, CreatedAt)

CustomerId, DealId, dan ProductId adalah pengenal stabil. DealProducts menyelesaikan relasi many-to-many: satu deal bisa memuat banyak produk, dan satu produk bisa muncul di banyak deal. DealNotes memisahkan catatan, jadi Anda tidak berakhir dengan kolom “Note 1, Note 2, Note 3”.

Sebelum memodelkan, laporan seperti “pendapatan per produk” berarti membelah string dan berharap orang mengetik nama konsisten. Setelah dimodelkan, itu menjadi query langsung pada DealProducts yang di-join ke Deals dan Products.

Langkah selanjutnya: dari skema ke aplikasi yang bekerja

Setelah skema Anda terlihat benar di atas kertas, pindahkan ke database nyata dan uji dengan data nyata. Jangan impor semuanya sekaligus. Muat batch kecil dulu, perbaiki yang rusak, lalu ulangi.

Urutan praktis yang menjaga risiko rendah:

• Buat tabel dan relasi.
• Impor 50 hingga 200 baris, verifikasi total, dan lakukan spot-check record.
• Perbaiki masalah pemetaan (kolom salah, ID hilang, duplikat), lalu impor ulang.
• Ketika stabil, muat sisanya.

Tambahkan aturan validasi sejak awal agar kebiasaan spreadsheet yang berantakan tidak kembali. Jadikan field wajib benar-benar wajib, batasi nilai yang diizinkan (misal status), validasi format (tanggal dan email), dan gunakan foreign key agar Anda tidak bisa membuat order untuk pelanggan yang tidak ada.

Lalu berhentilah menggunakan sheet untuk pembaruan. Melindungi data jauh lebih mudah ketika orang punya formulir sederhana dan alur kerja yang jelas.

Jika Anda ingin mengubah skema menjadi alat internal tanpa menulis kode, AppMaster (appmaster.io) bisa membantu: Anda memodelkan tabel dan relasi secara visual, lalu menghasilkan backend siap produksi, web app, dan aplikasi mobile native dari model yang sama.