TL;DR
Data contract adalah kesepakatan tertulis antara pihak yang ngirim data dan pihak yang makai data, isinya nama kolom, tipe data, boleh kosong atau nggak, seberapa sering diperbarui, dan siapa yang bertanggung jawab. Gunanya nyegah perubahan skema yang diam-diam bikin dashboard salah. Kamu bisa mulai tanpa tool khusus: satu file YAML sebagai isi kesepakatan, dan satu query ke information_schema yang ngecek kenyataannya masih cocok.
Data contract adalah kesepakatan tertulis antara pihak yang ngirim data dan pihak yang makai data, isinya bentuk data yang dijanjikan dan konsekuensi kalau bentuknya berubah.
Ini jawaban buat masalah yang tiap analis pernah alami. Suatu pagi dashboard nampilin nol, dan setelah dua jam nyari, ternyata developer ganti kolom status dari teks jadi angka minggu lalu. Nggak ada yang salah niat. Cuma nggak ada yang tau kolom itu dipakai siapa.
Data contract adalah dokumen yang nyebutin secara tegas struktur data yang dijanjikan sebuah sumber: nama kolom, tipe datanya, boleh kosong atau nggak, seberapa sering diperbarui, dan siapa yang bertanggung jawab kalau ada masalah. Dokumen ini dipasangin pengecekan otomatis, jadi begitu kenyataan nggak cocok sama janji, ada yang bunyi sebelum angka salah masuk laporan.
Bedanya sama dokumentasi biasa ada di satu kata: dicek. Dokumentasi yang nggak pernah diverifikasi bakal basi diam-diam. Kontrak yang dicek tiap hari nggak bisa basi tanpa ketahuan.
Tiga alasan yang paling sering muncul di kerjaan sehari-hari.
Perubahan hulu nggak keliatan sampai terlambat. Tim aplikasi ganti kolom karena alasan yang masuk akal buat mereka. Efeknya baru kerasa di ujung, di dashboard yang mereka nggak tau ada.
Kesalahannya sunyi. Kolom yang berubah dari teks ke angka jarang bikin query error. Dia bikin filter WHERE status = 'lunas' balikin nol baris, dan nol itu keliatan kayak angka yang sah.
Nggak ada yang ngaku pemilik. Tanpa kontrak, waktu ada masalah semua orang jawab "itu bukan tabel aku". Kontrak nulis satu nama di kolom pemilik.
Kontrak jaga bentuk data, sementara data quality jaga isinya. Keduanya beda kerjaan dan sama-sama perlu.
| Bagian | Isinya | Contoh |
|---|---|---|
| Skema | Nama kolom, tipe, boleh kosong atau nggak | status: text, wajib isi |
| Nilai yang sah | Daftar isi yang diizinkan | lunas, pending, batal |
| Kesegaran | Batas keterlambatan yang ditoleransi | Data kemarin siap sebelum jam 6 pagi |
| Volume wajar | Rentang jumlah baris harian | 800 sampai 2.500 baris |
| Pemilik | Nama orang dan saluran kontaknya | Tim kasir, kanal #data-kasir |
| Aturan perubahan | Apa yang boleh berubah dan gimana caranya | Tambah kolom bebas, ganti tipe lewat versi baru |
Enam bagian ini cukup buat sebagian besar tim. Jangan mulai dari template 40 kolom, isinya bakal separuh kosong dalam sebulan.
tabel: publik.transaksi
pemilik: tim-kasir
kanal: "#data-kasir"
versi: 1
kesegaran_jam: 6 # data kemarin siap sebelum jam 6 pagi
volume_harian_min: 800
volume_harian_max: 2500
kolom:
- nama: id
tipe: bigint
wajib: true
- nama: tanggal
tipe: date
wajib: true
- nama: total
tipe: numeric
wajib: true
- nama: status
tipe: text
wajib: true
nilai_sah: [lunas, pending, batal]
aturan_perubahan:
tambah_kolom: bebas
ganti_tipe: butuh versi baru dan masa tumpang tindih 14 hari
hapus_kolom: butuh versi baru dan masa tumpang tindih 14 hari
Simpan di repositori yang sama dengan query dashboardmu. File ini yang jadi rujukan waktu ada perdebatan.
PostgreSQL nyimpen bentuk tabel di information_schema.columns. Query ini balikin kenyataan hari ini.
SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'publik'
AND table_name = 'transaksi'
ORDER BY ordinal_position;
Bandingin hasilnya sama daftar kolom di YAML. Kalau ada yang beda, kontraknya dilanggar. Rincian tiap kolom di view ini ada di dokumentasi PostgreSQL.
-- Nilai status di luar kesepakatan
SELECT status, COUNT(*) AS jumlah
FROM publik.transaksi
WHERE tanggal = CURRENT_DATE - 1
AND status NOT IN ('lunas', 'pending', 'batal')
GROUP BY status;
-- Volume harian di luar rentang wajar
SELECT COUNT(*) AS baris_kemarin
FROM publik.transaksi
WHERE tanggal = CURRENT_DATE - 1;
Query pertama harus balikin nol baris. Query kedua harus jatuh di antara 800 dan 2.500.
Taruh ketiga query itu di satu skrip terjadwal. Kalau ada yang gagal, kirim pesan ke kanal pemiliknya. Alarm yang bunyi jam 6 pagi jauh lebih murah dari laporan salah yang dikirim jam 4 sore.
Sebagian isi kontrak bisa dipaksakan langsung sama database lewat CHECK dan NOT NULL.
ALTER TABLE publik.transaksi
ADD CONSTRAINT status_sah
CHECK (status IN ('lunas', 'pending', 'batal'));
Ini nolak data yang salah di pintu masuk, bukan cuma ngasih tau setelah masuk. Pembahasan lengkapnya ada di artikel CONSTRAINT di SQL.
Ini kejadian di dataset toko_berkah waktu aku bantu benerin pelaporannya.
Tim aplikasi kasir ganti kolom status dari teks jadi kode angka: 1 buat lunas, 2 buat pending, 3 buat batal. Alasannya masuk akal, hemat tempat dan lebih cepat diindeks.
Yang terjadi di hilir:
| Dampak | Rincian |
|---|---|
| Dashboard yang mati | 3 dari 11 |
| Lama nggak ketahuan | 5 hari |
| Selisih omzet yang dilaporkan | Rp 18.600.000 |
| Waktu ngelacak penyebabnya | 2 jam 20 menit |
Filter WHERE status = 'lunas' nggak error. Dia cuma balikin nol baris, dan tiga dashboard nampilin omzet Rp 0 yang keliatan kayak hari sepi.
Setelah kontrak dipasang, skenario yang sama diuji ulang di lingkungan percobaan. Pengecekan skema gagal 4 jam setelah perubahan, jauh sebelum ada laporan yang keluar. Waktu ngelacaknya turun dari 2 jam 20 menit jadi 6 menit, soalnya pesan alarmnya langsung nyebut nama kolom dan nama pemiliknya.
Buat nelusurin siapa aja yang kena waktu satu tabel berubah, data lineage yang ngerjain bagian itu.
Dua-duanya, dan itu justru intinya. Isinya dokumen yang bisa dibaca manusia, biasanya file YAML berisi daftar kolom beserta tipenya. Tapi file itu juga dipakai program buat ngecek kenyataan di database tiap hari. Kalau cuma jadi dokumen, dia bakal basi dalam dua bulan. Yang bikin dia hidup adalah pengecekan otomatis yang jalan tanpa diminta.
Data quality check nanya "isi datanya masuk akal nggak", misalnya ada berapa nilai kosong dan apakah ada harga negatif. Data contract nanya "bentuknya masih sesuai janji nggak", misalnya kolom status masih bertipe teks atau udah berubah jadi angka. Keduanya saling melengkapi. Kontrak jaga bentuknya, quality check jaga isinya.
Orang yang paling kesakitan kalau datanya rusak, dan itu biasanya analis. Kamu nggak perlu nunggu ada tim data engineering. Tulis kontrak buat lima tabel yang paling sering dipakai dashboard, kirim ke pemilik sistem sumbernya, lalu minta persetujuan lisan pun nggak apa-apa. Yang penting ada catatan tertulis tentang apa yang kamu andalkan.
Bikin aturan versi. Perubahan yang nambah kolom baru itu aman, langsung jalan. Perubahan yang ngubah tipe, ganti nama, atau ngehapus kolom harus lewat versi baru dengan masa tumpang tindih. Di tim yang aku bantu, masa tumpang tindihnya dua minggu, cukup buat semua dashboard menyesuaikan tanpa ada yang mati mendadak.
Kamu nggak bisa maksa vendor ikut aturanmu, tapi kamu tetap bisa bikin kontrak sepihak yang isinya harapanmu. Fungsinya jadi alarm: begitu ekspor dari vendor berubah bentuk, pengecekanmu langsung gagal dan kamu tau sebelum dashboard salah. Ini yang paling sering nyelametin, soalnya perubahan dari luar jarang diumumkan.
Tiga hal yang perlu dibawa:
Pilih satu tabel yang paling sering bikin dashboard-mu rusak. Tulis kontraknya sore ini, pasang query pengecek skemanya besok pagi. Itu udah nutup sebagian besar kejutan yang biasa datang.
Lanjut ke cek kualitas data pakai SQL buat ngejaga isinya, dan glossary ETL kalau kamu mau ngerti jalur datanya dulu.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.