Pemrosesan Data Transaksional

Dalam pemahaman awam Sistem pemrosesan data transaksional dianggap sebagai fungsi utama dalam komputasi bisnis. Sistem transaksional mencatat transaksi yang merangkum peristiwa spesifik yang ingin dilacak oleh organisasi. Suatu transaksi dapat berupa keuangan, seperti pergerakan uang antar rekening dalam sistem perbankan, atau mungkin merupakan bagian dari sistem ritel, melacak pembayaran barang dan jasa dari pelanggan. Pikirkan transaksi sebagai unit kerja yang kecil dan terpisah.

Sistem transaksi sering bervolume tinggi, terkadang menangani jutaan transaksi dalam satu hari. Data yang diproses harus dapat diakses dengan sangat cepat. Pekerjaan yang dilakukan oleh sistem transaksional sering disebut sebagai Online Transactional Processing (OLTP).

Solusi OLTP mengandalkan sistem database di mana penyimpanan data dioptimalkan untuk operasi baca dan tulis untuk mendukung beban kerja transaksional di mana catatan data dibuat (create), diambil (read), diperbarui (update), dan dihapus(delete) (sering disebut sebagai operasi CRUD) . Operasi ini diterapkan secara transaksional, dengan cara memastikan integritas data yang disimpan dalam database. Untuk mencapai hal ini, sistem OLTP memberlakukan transaksi yang mendukung apa yang disebut semantik ACID. ACID adalah kependekan dari Atomicity (Atomisitas), Consistency (Konsistensi), Isolation (Isolasi), dan Durability (Daya tahan).

Atomicity (Atomicitas)

Transaksi harus dianggap sebagai satu operasi atomik atau satu kesatuan yang tidak dapat dibagi-bagi. Artinya, transaksi harus dilaksanakan sepenuhnya atau tidak sama sekali. Jika salah satu bagian transaksi gagal, maka keseluruhan transaksi harus dibatalkan (rollback), sehingga database tidak akan berada dalam keadaan setengah terupdate.

Misalnya, transaksi yang melibatkan pendebitan dana dari satu akun dan mengkredit jumlah yang sama ke akun lain harus menyelesaikan kedua tindakan tersebut. Jika salah satu tindakan tidak dapat diselesaikan, maka tindakan lainnya harus gagal.

Secara teknis, jika sebuah transaksi melibatkan perubahan data pada dua tabel yang berbeda, dan salah satu operasi tersebut gagal, maka kedua operasi harus dibatalkan dan data harus dikembalikan ke keadaan semula. Hal ini memastikan bahwa basis data tetap konsisten dan tidak terjadi inkonsistensi data yang dapat mengacaukan sistem secara keseluruhan.

Berikut adalah contoh satu transaksi menggunakan MySQL: Misalkan terdapat tabel “produk” dengan kolom “id_produk”, “nama_produk”, “harga”, dan “jumlah_stok”. Untuk memperbarui jumlah stok suatu produk setelah dilakukan pembelian, dilakukan transaksi sebagai berikut:

START TRANSACTION; -- Mulai transaksi

UPDATE produk SET jumlah_stok = jumlah_stok - 10 WHERE id_produk = 1; -- Mengurangi stok produk dengan id_produk = 1 sebanyak 10

INSERT INTO log_transaksi (id_produk, jumlah_beli, waktu_beli) VALUES (1, 10, NOW()); -- Menambahkan catatan transaksi pada tabel log_transaksi

COMMIT; -- Menyelesaikan transaksi dan menyimpan perubahan

Dalam contoh di atas, transaksi dimulai dengan perintah “START TRANSACTION”. Kemudian, dilakukan perubahan pada jumlah stok produk dengan id_produk = 1 menggunakan perintah “UPDATE”. Setelah itu, dilakukan penambahan catatan transaksi pada tabel “log_transaksi” menggunakan perintah “INSERT INTO”. Setelah semua perintah selesai dieksekusi, transaksi diselesaikan dengan perintah “COMMIT”, yang akan menyimpan perubahan-perubahan yang telah dilakukan pada database.

Namun, jika terjadi kesalahan selama transaksi, maka transaksi akan dibatalkan dengan perintah “ROLLBACK”. Dengan menggunakan transaksi, perubahan pada database dapat dilakukan dengan aman dan terjamin keberhasilannya, dan kesalahan dapat dihindari atau diatasi dengan cepat.

Consistency (Konsistensi)

Transaksi harus memastikan bahwa semua perubahan yang dilakukan dalam transaksi mempertahankan keadaan konsisten basis data. Artinya, transaksi tidak boleh membuat basis data dalam keadaan yang tidak konsisten. Transaksi hanya dapat mengambil data dalam database dari satu status valid ke status lainnya. Untuk melanjutkan contoh debet dan kredit di atas, status selesai transaksi harus mencerminkan transfer dana dari satu akun ke akun lainnya.

Saat menjalankan perintah untuk menambahkan data ke dalam sebuah tabel, pastikan bahwa data yang dimasukkan sesuai dengan jenis tipe data pada kolom yang ditentukan dan referensi integritas yang diterapkan pada tabel tersebut. Jika terdapat pelanggaran pada aturan tersebut, maka MySQL akan mengembalikan pesan kesalahan dan tidak menambahkan data ke dalam tabel.

Sebagai contoh, misalkan terdapat dua tabel “orders” dan “customers”. Kolom “customer_id” pada tabel “orders” merupakan kunci asing (foreign key) yang merujuk pada kolom “id” pada tabel “customers”. Jika kita ingin menambahkan sebuah order baru ke dalam tabel “orders”, kita harus memastikan bahwa “customer_id” yang kita masukkan merupakan id yang valid pada tabel “customers”. Berikut ini adalah contoh perintah SQL yang menjaga konsistensi data pada MySQL:

INSERT INTO orders (order_id, customer_id, order_date, total_amount)
VALUES (12345, 1001, '2023-03-07', 500000)

Perintah di atas akan menambahkan sebuah order baru ke dalam tabel “orders” dengan id_order = 12345, customer_id = 1001, order_date = ‘2023-03-07’, dan total_amount = 500000. Karena “customer_id” merupakan kunci asing yang merujuk pada kolom “id” pada tabel “customers”, MySQL akan memastikan bahwa nilai yang dimasukkan ke dalam kolom “customer_id” merupakan id yang valid pada tabel “customers”. Jika tidak, maka MySQL akan mengembalikan pesan kesalahan dan tidak menambahkan data ke dalam tabel “orders”. Dengan cara ini, konsistensi data pada database tetap terjaga.

Isolation (Isolasi)

Transaksi bersamaan tidak dapat mengganggu satu sama lain, dan harus menghasilkan status database yang konsisten. Jika dua transaksi berjalan pada saat yang sama, maka sistem harus dapat menjalankan keduanya secara independen dan menghindari efek samping dari satu transaksi terhadap transaksi lain. Misalnya, saat transaksi untuk mentransfer dana dari satu akun ke akun lain sedang dalam proses, transaksi lain yang memeriksa saldo akun ini harus memberikan hasil yang konsisten – transaksi pemeriksaan saldo tidak dapat mengambil nilai untuk satu akun yang mencerminkan saldo sebelum transfer, dan nilai untuk akun lain yang mencerminkan saldo setelah transfer.

Isolasi pada database adalah kemampuan untuk membatasi akses atau pengaruh dari transaksi lain terhadap sebuah transaksi tertentu, sehingga mencegah terjadinya konflik dan konsistensi data tetap terjaga.

Misalkan terdapat dua transaksi yang sedang berjalan di database. Transaksi pertama (T1) melakukan pembelian barang dengan mengurangi jumlah stok pada tabel “produk”, sedangkan transaksi kedua (T2) melakukan penambahan jumlah stok pada tabel yang sama.

-- Transaksi pertama (T1)
START TRANSACTION;
SELECT jumlah_stok FROM produk WHERE id_produk = 1; -- membaca jumlah stok saat ini
UPDATE produk SET jumlah_stok = jumlah_stok - 10 WHERE id_produk = 1; -- mengurangi stok sebanyak 10
COMMIT;

-- Transaksi kedua (T2)
START TRANSACTION;
UPDATE produk SET jumlah_stok = jumlah_stok + 5 WHERE id_produk = 1; -- menambahkan stok sebanyak 5
COMMIT;

Jika level isolation READ COMMITTED digunakan, maka transaksi kedua (T2) akan menunggu sampai transaksi pertama (T1) selesai di-commit sebelum melakukan perubahan pada tabel “produk”. Artinya, ketika T2 membaca jumlah stok pada tabel “produk”, ia hanya membaca nilai terakhir yang di-commit oleh T1. Jadi, jika T1 mengurangi jumlah stok sebanyak 10, maka ketika T2 membaca nilai tersebut, nilai jumlah stok yang terbaca sudah dikurangi sebanyak 10 oleh T1, sehingga T2 hanya menambahkan nilai tersebut dengan 5.

Dengan demikian, isolasi pada level READ COMMITTED memastikan bahwa setiap transaksi hanya melihat nilai terakhir yang di-commit oleh transaksi sebelumnya, sehingga menghindari terjadinya konflik pada data dan menjaga konsistensi data pada database.

Durability (Daya Tahan)

Perubahan data yang dilakukan oleh transaksi harus dipertahankan bahkan jika terjadi kegagalan sistem atau hardware. Artinya, data yang telah diubah oleh transaksi harus tahan terhadap gangguan sistem atau perangkat keras, seperti kerusakan pada server atau pemadaman listrik. Ketika transaksi telah dilakukan, itu akan tetap dilakukan. Misalnya, Setelah transaksi transfer akun selesai, saldo akun yang telah direvisi tetap ada sehingga meskipun sistem database dimatikan, transaksi yang dilakukan akan tercermin saat diaktifkan kembali. Contoh lain, misalkan terdapat sebuah transaksi yang mengubah data pada tabel “produk” dengan melakukan perubahan pada kolom “harga”.

-- Transaksi
START TRANSACTION;
UPDATE produk SET harga = harga + 1000 WHERE id_produk = 1; -- mengubah harga
COMMIT;

Jika sistem atau hardware mengalami kegagalan atau kerusakan saat transaksi sedang berlangsung atau segera setelah transaksi di-commit, maka perubahan yang telah dilakukan pada tabel “produk” tidak boleh hilang atau terhapus. Oleh karena itu, sistem harus menyediakan fitur logging yang memastikan bahwa semua perubahan data yang dilakukan oleh sebuah transaksi dicatat dalam log atau jurnal (log file) sebelum di-commit.

Dalam hal ini, sistem akan mencatat perubahan yang dilakukan oleh transaksi dalam log atau jurnal sebelum melakukan commit. Dengan begitu, jika terjadi kegagalan sistem atau kerusakan hardware, sistem dapat memulihkan data yang hilang atau rusak dengan menggunakan informasi yang tercatat dalam log atau jurnal.

Dengan demikian, durability pada sistem memastikan bahwa semua perubahan yang dilakukan pada database tetap terjaga dan dapat dipulihkan meskipun terjadi kegagalan sistem atau kerusakan hardware.

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *