Data Contract: Kesepakatan Supaya Kolom Tidak Berubah Diam-diam

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.

Apa itu data contract?

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.

Kenapa analis perlu data contract?

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.

Isi data contract itu apa aja?

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.

Gimana cara bikin data contract tanpa tool khusus?

Langkah 1: Tulis kontraknya sebagai file YAML

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.

Langkah 2: Cek skema nyata pakai SQL

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.

Langkah 3: Cek nilai yang sah dan volume

-- 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.

Langkah 4: Jalanin tiap pagi

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.

Langkah 5: Pasang penjaga di database

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.

Contoh kasus: kolom status yang berubah tipe

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.

Kesalahan umum waktu bikin data contract

• Bikin kontrak buat semua tabel. Mulai dari lima tabel yang paling banyak dipakai dashboard. Sisanya nyusul.
• Kontrak tanpa pengecekan otomatis. Dokumen yang nggak pernah diuji bakal beda dari kenyataan dalam dua bulan.
• Alarm yang terlalu berisik. Rentang volume yang kesempitan bikin alarm bunyi tiap hari libur. Orang bakal berhenti baca.
• Nggak nulis nama pemilik. Alarm yang nggak jelas ditujukan ke siapa bakal dibaca semua orang dan ditindaklanjuti nol orang.
• Ngelarang semua perubahan. Sistem hidup pasti berubah. Yang diatur caranya, bukan larangannya.
• Nyimpen kontrak di dokumen terpisah yang jarang dibuka. Taruh sedekat mungkin sama kode yang mengandalkannya.

FAQ

Data contract itu dokumen atau kode?

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.

Bedanya data contract sama data quality check apa?

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.

Siapa yang harus bikin data contract di tim kecil?

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.

Gimana cara nanganin perubahan yang memang harus terjadi?

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.

Kalau sumber datanya dari vendor luar, kontraknya gimana?

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.

Penutup

Tiga hal yang perlu dibawa:

1. Data contract nulis bentuk data yang dijanjikan, plus siapa yang bertanggung jawab.
2. Yang bikin dia berguna itu pengecekan otomatis, bukan dokumennya.
3. Mulai dari lima tabel paling penting, satu file YAML, dan tiga query.

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.