Manajemen Database Drillhole: Dari Log Lapangan ke Estimasi Sumber Daya

Korupsi data termahal yang pernah kulihat bukan disebabkan oleh bug software. Itu disebabkan oleh seorang geologist di kamp lapangan di Kalimantan yang mengurutkan spreadsheet assay berdasarkan kolom Au tanpa memilih semua kolom. Hole ID tetap di tempatnya. Assay bergeser ke bawah 12 baris. 84 sampel ditetapkan ke lubang yang salah. Error merambat melalui compositing, variografi, dan kriging. Pernyataan sumber daya diterbitkan dengan data yang salah. Error itu tertangkap enam bulan kemudian selama review due-diligence — olehku, memeriksa satu intersection high-grade terhadap sertifikat lab asli.

Ini bukan jenis kegagalan yang langka. Database drillhole itu rapuh, dan cara pengelolaannya pada proyek-proyek Indonesia — spreadsheet kamp lapangan di-email ke Jakarta, digabung ke file master, di-ekspor ulang untuk estimasi — menciptakan banyak titik kegagalan. Checklist validasi drillhole menangkap masalah kualitas data di tahap estimasi. Tulisan ini tentang mencegah masalah di tahap manajemen, sebelum mencapai estimasi.

Struktur empat tabel

Setiap database drillhole memiliki empat tabel inti. Memahami hubungan mereka adalah fondasi integritas data.

1. Tabel Collar

Satu baris per lubang. Berisi: hole_id, easting, northing, elevasi, max_depth, hole_type (DDH/RC/AC), azimuth, dip.

Primary key: hole_id. Harus unik. Tidak ada duplikat, selamanya.

2. Tabel Survey

Satu baris per stasiun survey downhole. Berisi: hole_id, depth, azimuth, dip.

Foreign key: hole_id → collar.hole_id. Setiap hole_id survey harus ada di tabel collar.

Aturan integritas: Kedalaman survey harus ≤ collar.max_depth untuk lubang yang sama. Survey di kedalaman 250m pada lubang dengan max_depth 200m adalah error data.

3. Tabel Assay

Satu baris per interval assay. Berisi: hole_id, from, to, Au, Cu, Pb, Zn, Ag, … (sebanyak elemen yang di-assay).

Foreign key: hole_id → collar.hole_id.

Aturan integritas:

• from < to untuk setiap baris
• Tidak ada interval yang tumpang tindih dalam lubang yang sama
• Tidak ada celah yang lebih besar dari yang diizinkan protokol sampling (misalnya, jika kamu menyampling setiap 2m, celah 10m mencurigakan)
• Nilai BDL (below detection limit) harus dikodekan secara konsisten (misalnya, -1, 0, atau nilai batas deteksi — pilih satu dan dokumentasikan)

4. Tabel Geologi

Satu baris per interval yang di-log. Berisi: hole_id, from, to, lithology_code, weathering_code, alteration_code, structure_code.

Foreign key: hole_id → collar.hole_id.

Aturan integritas: Sama seperti assay — from < to, tidak ada tumpang tindih, tidak ada celah yang tidak terduga.

Hubungan yang rusak

Hubungan foreign key adalah tempat korupsi masuk. Empat mode kegagalan yang aku lihat berulang kali:

Kegagalan 1: Rekam yatim piatu

Baris assay dengan hole_id “DDH-047” yang tidak ada di tabel collar. Biasanya disebabkan oleh typo (DDH-047 vs DDH_047 vs DDH047). Software estimasi bisa crash atau secara diam-diam membuang rekaman tersebut.

Pencegahan: Terapkan integritas referensial saat impor. Setiap hole_id di survey, assay, dan geologi harus ada di collar. Tolak impor jika tidak.

Kegagalan 2: Tumpang tindih interval

Dua baris assay untuk lubang yang sama dengan interval from-to yang tumpang tindih: 10,0-12,0 dan 11,5-13,5. Software estimasi tidak tahu assay mana yang digunakan untuk interval 11,5-12,0.

Pencegahan: Urutkan berdasarkan hole_id, lalu berdasarkan from. Periksa bahwa setiap baris from ≥ to baris sebelumnya dalam lubang yang sama. Flag tumpang tindih saat impor.

Kegagalan 3: Korupsi sortir tanpa pilih-semua

Ini adalah kasus Kalimantan. Pengguna mengurutkan berdasarkan satu kolom tanpa memilih semua kolom. Baris menjadi tidak selaras. Hole ID tidak lagi sesuai dengan assay yang benar.

Pencegahan: Jangan pernah mengedit database di spreadsheet setelah impor. Gunakan antarmuka edit alat database, yang menegakkan integritas tingkat baris. Jika harus menggunakan spreadsheet untuk entri data, gunakan satu sheet dengan semua kolom terkunci kecuali yang sedang diedit, dan jangan pernah mengurutkan.

Kegagalan 4: Version drift

Kamp lapangan memiliki database versi 3. Jakarta memiliki versi 4. Konsultan estimasi memiliki versi 5. Tiga versi kebenaran. Estimasi sumber daya menggunakan versi 5. Reviewer due-diligence diberi versi 3.

Pencegahan: Single source of truth. Satu database, satu lokasi, satu versi. Kamp lapangan mengirimkan data melalui upload (bukan lampiran email), dan upload menciptakan versi baru dengan timestamp dan nama kontributor. Master database tidak pernah diedit — hanya ditambahi.

Workflow kamp-lapangan-ke-kantor Indonesia

Workflow tipikal pada proyek Indonesia:

1. Kamp lapangan: Geologist mencatat core, memasukkan data ke spreadsheet, meng-emailnya ke kantor Jakarta mingguan
2. Kantor Jakarta: Manajer data menerima email, menyalin data ke spreadsheet master, mengirim master ke konsultan estimasi bulanan
3. Konsultan estimasi: Menerima spreadsheet master, mengimpor ke software estimasi, menjalankan estimasi
4. Review CP: CP menerima laporan estimasi dan file data, mereview, menandatangani

Di mana ia rusak:

• Langkah 1 → 2: Lampiran email hilang. Kamp lapangan mengirim “DDH_assay_week3.xlsx” tapi Jakarta sudah memiliki file dengan nama itu dari proyek berbeda. Overwrite terjadi. Data hilang.
• Langkah 2 → 3: Spreadsheet master memiliki 15 tab, beberapa dengan formula, beberapa dengan nilai hard-coded. Konsultan mengimpor tab yang salah. Atau formula tidak kalkulasi karena spreadsheet dibuka di versi Excel yang berbeda.
• Langkah 3 → 4: Impor konsultan menciptakan database baru di software estimasi. CP mereview laporan tapi tidak memeriksa ulang impor terhadap data asli. Jika impor salah, error sudah terpanggang ke dalam laporan yang ditandatangani.

Perbaikannya: Sistem database tunggal yang diakses semua pihak. Kamp lapangan memasukkan data melalui web form atau meng-upload CSV. Sistem memvalidasi saat entri (integritas referensial, tumpang tindih interval, pengkodean BDL). Jakarta dan konsultan mengakses database yang sama. CP dapat mengaudit log impor. Version control otomatis — setiap perubahan diberi timestamp dan atribusi.

Jika sistem database penuh tidak tersedia, minimumnya adalah:

• Satu master CSV per tabel (collar, survey, assay, geologi)
• Penomoran versi (v1, v2, v3 — jangan pernah overwrite, selalu buat versi baru)
• Change log (apa yang berubah antar versi, siapa yang membuat perubahan, kapan)
• Checksum MD5 pada file untuk mendeteksi korupsi diam-diam selama transfer

Validasi impor — garis pertahanan terakhir

Sebelum data apa pun masuk ke database estimasi, jalankan cek ini:

Cek ini tidak bisa ditawar. Panduan memulai memandu bagaimana Orebit GeoSuite menjalankan semua ini secara otomatis saat impor.

Version control dan audit trail

Setiap estimasi sumber daya harus dapat direproduksi dari database. Itu berarti:

1. Versi database: Nomor versi atau hash yang secara unik mengidentifikasi keadaan data yang digunakan untuk estimasi
2. Log parameter: Setiap parameter estimasi (top-cut, panjang komposit, model variogram, search ellipsoid) dicatat dengan tanggal dan orang yang menetapkannya
3. Log output: Tanggal dan parameter setiap kali estimasi dijalankan, dengan nama file output
4. Change log: Setiap perubahan pada database setelah estimasi, dengan tanggal, orang, dan alasan

Jika auditor bertanya “data apa yang digunakan untuk estimasi sumber daya Desember 2025?”, kamu harus bisa menunjuk ke versi database dan set parameter tertentu. Jika tidak bisa, estimasinya tidak dapat diaudit.

Checklist validasi block model mengasumsikan data itu benar. Jika database rusak, validasi akan lolos — model konsisten dengan data, tapi data salah. Manajemen database adalah kontrol hulu yang membuat validasi bermakna.

Bagaimana Orebit GeoSuite membantu

Orebit Core (Fase 01) dibangun sebagai alat manajemen database, bukan sekadar validator:

• Impor CSV dengan validasi: Upload CSV collar, survey, assay, geologi. Setiap impor menjalankan 10 cek di atas. Kegagalan dilaporkan dengan nomor baris dan pesan error spesifik. Kamu perbaiki data dan upload ulang — alat tidak akan mengimpor data yang rusak.
• Database tunggal: Setelah impor, data hidup dalam database terstruktur tunggal dalam alat. Tidak ada spreadsheet, tidak ada version drift, tidak ada korupsi sortir-tanpa-pilih-semua.
• Audit trail: Setiap impor diberi timestamp. Setiap perubahan parameter di-log. Kamu dapat merekonstruksi keadaan data yang tepat di setiap titik waktu.
• Ekspor untuk estimasi: Database mengekspor CSV bersih untuk Orebit Assay (Fase 02) dan Orebit Resource (Fase 03). Tidak ada penanganan data manual antar fase.
• Checksum MD5: Setiap ekspor menyertakan file checksum. Jika file rusak selama transfer, checksum tidak akan cocok.
• Perbandingan versi: Jika kamu mengimpor data baru, alat menunjukkan apa yang berubah (lubang baru, assay baru, rekaman yang dimodifikasi) dibandingkan versi sebelumnya.

Coba Core gratis → · Ambil bundle — Rp 99K → (modul satuan Rp 49K · sekali bayar · jadi milikmu selamanya)

Intinya

Estimasi sumber daya-mu hanya sebaik database-mu. Kriging paling canggih tidak bisa memperbaiki data yang rusak. CP paling berpengalaman tidak bisa menangkap ketidakselarasan 12 baris dengan melihat laporan. Disiplin manajemen database — integritas referensial, version control, audit trail, validasi impor — adalah apa yang membuat seluruh rantai estimasi sumber daya dapat dipercaya. Perlakukan database sebagai aset, bukan estimasinya.

Punya kekhawatiran tentang integritas database-mu? Email hello@orebit.id dengan ukuran database (jumlah lubang, jumlah sampel) dan aku akan bilang apa yang harus diperiksa pertama.