Jumat

Perbaikan Tampilan Sistem melalui Phpmyadmin #editsistem

Prosedur Eksplorasi Database - Comic Style

Eksplorasi & Diagnosa Database via phpMyAdmin

1. Audit Struktur Tabel

Langkah pertama dalam strategi perbaikan tampilan hasil uji adalah melakukan audit terhadap struktur tabel yang ada. Administrator perlu memastikan tidak ada kerusakan pada metadata atau indeks yang menyebabkan data tidak tampil di aplikasi meskipun sudah ada di database. Perintah SQL dasar seperti DESCRIBE atau SHOW CREATE TABLE memberikan gambaran teknis mengenai bagaimana data disimpan dan batasan apa yang berlaku.

t_imltd_results PK: id (AUTO_INC) FK: no_kantong

2. Analisis Struktur & Constraint

Melalui tab "SQL" di phpMyAdmin, administrator dapat menjalankan perintah berikut untuk memverifikasi struktur tabel IMLTD:

DESCRIBE t_imltd_results;

Hasil dari perintah ini akan menampilkan kolom, tipe data, apakah kolom boleh kosong (null), dan kunci mana yang digunakan. Penting untuk diperhatikan kolom dengan atribut AUTO_INCREMENT, karena saat melakukan impor data manual, kolom ini harus diperlakukan secara khusus agar tidak merusak urutan penomoran unik.

Selain struktur fisik, administrator harus memeriksa "Relation View" di phpMyAdmin untuk melihat hubungan kunci asing. Jika kolom no_kantong di tabel IMLTD terhubung dengan RESTRICT atau CASCADE ke tabel donor, maka perubahan pada identitas donor dapat berdampak langsung pada tampilan hasil uji. Ketidakterhubungan otomatis antara mesin dan server sering kali menyebabkan data kantong darah sudah ada di tabel stok, namun entri di tabel IMLTD masih kosong, sehingga aplikasi menampilkan status "Menunggu Hasil" atau "Pending".

ERROR: 404 DATA NOT FOUND

3. Diagnosa Penyebab Data Hilang

Sering kali, masalah "tampilan hasil tidak muncul" bukan disebabkan oleh ketiadaan data, melainkan oleh ketidakcocokan format. Berikut adalah beberapa penyebab teknis yang sering ditemukan:

  • Leading/Trailing Spaces: Nomor kantong darah pada hasil ekspor mesin seringkali mengandung spasi tambahan (misal: " 2305001") yang membuatnya tidak cocok dengan data di SIMDONDAR saat dilakukan kueri JOIN.
  • Karakter Non-Printable: Masalah encoding file CSV (seperti UTF-8 dengan BOM) dapat menyisipkan karakter tersembunyi di awal baris pertama.
  • Status Verifikasi: Aplikasi SIMDONDAR biasanya hanya menampilkan hasil yang kolom is_verified atau status_verifikasi-nya bernilai 1. Jika data masuk melalui phpMyAdmin namun kolom ini tetap 0, maka petugas di bagian distribusi tidak akan melihat hasil tersebut.

4. Deteksi Data "Menggantung"

Untuk mendeteksi data yang "menggantung" (ada di database tapi tidak muncul di aplikasi), administrator dapat menjalankan kueri perbandingan:

SELECT a.no_kantong
FROM t_stok a
LEFT JOIN t_imltd b ON a.no_kantong = b.no_kantong
WHERE b.no_kantong IS NULL;

Kueri ini akan menampilkan daftar nomor kantong darah yang sudah diambil darahnya (aftap) namun belum memiliki rekaman hasil uji saring IMLTD.

5. Koreksi Data Per Baris

Strategi pemutakhiran data manual dan batch melalui SQL dilakukan ketika mesin pemeriksa tidak terintegrasi. Koreksi manual dilakukan jika terdapat kesalahan entri oleh petugas laboratorium atau jika hasil pemeriksaan ulang (duplo) mengubah status reaktivitas sampel.

Dalam phpMyAdmin, fitur "Edit" menyediakan antarmuka visual, namun penggunaan kueri SQL UPDATE lebih direkomendasikan karena meninggalkan jejak yang lebih jelas di log server.

Langkah koreksi aman:

  • Cari nomor kantong darah spesifik menggunakan kueri SELECT.
  • Pastikan data yang akan diubah adalah benar milik kantong tersebut.
  • Jalankan perintah pemutakhiran dengan klausa WHERE yang sangat spesifik.
UPDATE t_imltd
SET hbsag_status = 'NR',
    keterangan = 'Koreksi hasil pemeriksaan ulang tanggal 2024-05-12',
    updated_at = NOW()
WHERE no_kantong = 'XYZ-2024-10029'
LIMIT 1;

Penggunaan LIMIT 1 adalah praktik terbaik (best practice) keamanan untuk memastikan bahwa jika terjadi kesalahan logika dalam klausa WHERE, perubahan tidak akan merembet ke baris data lainnya.

6. Blokir Stok & Status Reaktif

Aspek paling krusial adalah memastikan bahwa setiap hasil 'R' (Reaktif) di tabel IMLTD tersinkronisasi dengan status fisik kantong darah. Administrator harus menjalankan kueri sinkronisasi setelah setiap sesi penginputan data.

Logika Sinkronisasi:
  • Semua 'NR' ➔ Status = 'Tersedia' (Siap kirim)
  • Salah Satu 'R' ➔ Status = 'Blokir/Musnah' (Dicekal)
  • Greyzone ➔ Status = 'Karantina' (Tunggu konfirmasi)

Kueri otomatisasi blokir:

UPDATE t_stok s
JOIN t_imltd i ON s.no_kantong = i.no_kantong
SET s.status_distribusi = 'DICEKAL',
    s.keterangan_blokir = 'Reaktif IMLTD'
WHERE i.hbsag_status = 'R'
   OR i.hcv_status = 'R'
   OR i.hiv_status = 'R'
   OR i.sifilis_status = 'R';

Kueri ini memastikan integritas sistem terjaga. Tanpa langkah ini, ada risiko teknis di mana hasil IMLTD sudah tercatat reaktif, namun sistem stok masih menganggap darah tersebut layak pakai karena pemicu (trigger) aplikasi tidak berjalan saat perubahan dilakukan via phpMyAdmin.

CSV

7. Impor Data Massal (CSV)

Untuk mengatasi volume data besar dari mesin ChLIA atau ELISA, metode impor file CSV atau Excel adalah strategi paling efisien. Tahap transformasi data (Pre-Processing) sangat krusial:

  • Pastikan format tanggal sesuai MySQL (YYYY-MM-DD).
  • Konversi kode hasil (misal "Non-Reactive" jadi "NR").
  • Delimiter: Gunakan koma (,) atau titik koma (;) konsisten.
  • Enclosure: Gunakan tanda kutip ganda (").
  • Encoding: UTF-8 without BOM (untuk hindari karakter aneh).

Jika terjadi kesalahan "Duplicate entry", gunakan perintah LOAD DATA LOCAL INFILE dengan klausa REPLACE:

LOAD DATA LOCAL INFILE 'C:/data/hasil.csv'
REPLACE INTO TABLE t_imltd
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\r\n'
IGNORE 1 LINES
(no_kantong, hbsag_status, ...);

Penggunaan REPLACE sangat berguna jika hasil pemeriksaan pertama adalah reaktif awal dan hasil kedua (setelah diulang) adalah non-reaktif, sehingga sistem akan menyimpan hasil yang paling valid dan terbaru.

8. Keamanan & Audit Trail

Melakukan perubahan database langsung melalui phpMyAdmin membawa risiko keamanan. Informasi IMLTD adalah data medis sensitif. Strategi ini harus dibarengi protokol ketat.

Administrator disarankan membuat tabel audit tambahan atau menggunakan Trigger yang secara otomatis mencatat setiap perubahan:

CREATE TRIGGER audit_imltd_update
AFTER UPDATE ON t_imltd
FOR EACH ROW
INSERT INTO t_log_aktivitas 
(user, aksi, no_kantong, nilai_lama, nilai_baru, waktu)
VALUES (CURRENT_USER(), 'UPDATE_IMLTD', OLD.no_kantong, 
OLD.hbsag_status, NEW.hbsag_status, NOW());

Dengan mekanisme ini, jika terjadi sengketa medis, UDD PMI XYZ dapat membuktikan siapa yang melakukan perubahan data, kapan, dan alasannya.

Akses ke phpMyAdmin harus dibatasi dengan otentikasi dua faktor (2FA) dan IP Whitelisting, serta berjalan di atas protokol HTTPS terenkripsi. Administrator juga harus rutin menjalankan kueri pembersihan untuk mengidentifikasi baris ganda (redundansi) agar tampilan sistem informasi tidak membingungkan.

INFOGRAFIS TEKNIS - DATABASE & IMLTD

di

Infaq Imam Ahmad Rahimahullah

Widget Komik Sedekah ...