{"id":346,"date":"2025-03-25T14:35:35","date_gmt":"2025-03-25T07:35:35","guid":{"rendered":"https:\/\/binus.ac.id\/semarang\/information-systems\/?p=346"},"modified":"2025-03-25T14:40:15","modified_gmt":"2025-03-25T07:40:15","slug":"transaction-properties-dalam-database","status":"publish","type":"post","link":"https:\/\/binus.ac.id\/semarang\/information-systems\/2025\/03\/25\/transaction-properties-dalam-database\/","title":{"rendered":"Transaction Properties dalam Database"},"content":{"rendered":"

Seperti yang kita tahu, database <\/em>merupakan kumpulan data yang terorganisir dan saling berhubungan dalam suatu sistem komputer. Di dalam suatu database <\/em>yang besar (seperti database <\/em>perusahaan yang menyimpan data transaksi ribuan pelanggan), jutaan request <\/em>per-detik bisa diproses di dalam database. <\/em>Banyaknya request <\/em>yang masuk seringkali \u201cmenyentuh\u201d komponen yang sama di database<\/em>, sehingga bisa menimbulkan permasalahan jika tidak dikelola dengan baik.<\/p>\n

Untuk lebih jelasnya, bayangkan jika Anda sedang mengikuti suatu flash sale <\/em>di salah satu e-commerce platform, <\/em>dan Anda sedang berusaha untuk membeli barang X. Saat flash sale <\/em>dimulai, Anda segera memasukkan barang X ke keranjang, lalu mencoba untuk checkout. <\/em>Namun, di saat yang sama, ribuan pengguna lain ternyata juga ingin membeli barang tersebut; mereka memasukkan barang X ke keranjang masing-masing, lalu mencoba untuk checkout <\/em>di waktu yang sama dengan Anda. Dalam kasus ini, database<\/em> harus memastikan jumlah stock <\/em>yang tersisa agar total pembelian yang dilakukan tidak melebihi total stock <\/em>yang dimiliki oleh store<\/em> barang X. Nah, bisanya, database transaction <\/em>digunakan dalam kasus seperti ini.<\/p>\n

Namun, apa sebenarnya database transaction <\/em>itu? Apakah database transaction <\/em>memiliki mekanisme tertentu untuk menjaga keamanan datanya? Lalu, apa saja prinsip-prinsip yang diterapkan dalam database transaction<\/em>? Semua pertanyaan ini akan dibahas di bagian selanjutnya.<\/p>\n

Konsep Database<\/em> Transaction<\/em><\/strong><\/p>\n

Database transaction <\/em>(atau dalam Bahasa Indonesia disebut \u201ctransaksi basis data\u201d) merupakan suatu runtutan operasi dalam database <\/em>yang diperlakukan sebagai satu unit (kesatuan) kerja yang logis. Unit kerja ini harus diselesaikan secara keseluruhan atau dibatalkan secara keseluruhan, yang artinya transaksi tidak bisa diselesaikan setengah-setengah. Misalnya, dalam kasus transaksi pembelian di e-commerce<\/em>, tidak bisa bila database <\/em>hanya meng-update <\/em>data inventori atau data accounts receivable <\/em>(pembayaran yang diterima) karena transaksi yang dilakukan sebetulnya mempengaruhi kedua hal tersebut. Jika ada proses transaksi yang gagal, keseluruhan database<\/em> harus dikembalikan ke kondisi semula seperti sebelum transaksi tersebut dijalankan.<\/p>\n

Ketika database transaction <\/em>dijalankan (sedang dalam suatu proses sehingga masih terus diubah), kondisi database <\/em>tersebut menjadi tidak konsisten untuk sementara. Namun, ketika transaksinya di-commit <\/em>(difinalisasi), perubahan yang dilakukan akan disimpan dan diterapkan sehingga sudah tidak dapat di-undo<\/em> (dalam database transaction<\/em>, konsep \u201cundo<\/em>\u201d ini disebut dengan rollback<\/em>).<\/p>\n

Contoh database transaction <\/em>yang mudah ditemukan dalam hidup sehari-hari adalah transfer antar rekening. Anggap saja Anda ingin memindahkan 5 dollar dari rekening A ke B. Proses ini dapat dipecah menjadi beberapa operasi dasar sederhana, yaitu:<\/p>\n

    \n
  1. Membuat record <\/em>atau catatan transaksi untuk transfer 5 dollar dari rekening A ke B (tahap awal dari database transaction<\/em>).<\/li>\n
  2. Membaca saldo yang ada dari rekening A.<\/li>\n
  3. Mengurangi 5 dollar dari rekening A.<\/li>\n
  4. Membaca saldo yang ada di rekening B.<\/li>\n
  5. Menambahkan 5 dollar ke rekening B.<\/li>\n<\/ol>\n

    Nah, jika tiba-tiba terjadi eror pada sistem atau mati listrik saat transaksi masih dijalankan, transaksi tersebut bisa di-undone<\/em> sehingga database<\/em> akan dikembalikan ke kondisi awalnya (seperti saat sebelum transaksi dijalankan). Biasanya, istilah \u201crollback<\/em>\u201d digunakan untuk merujuk pada proses yang meng-undo <\/em>perubahan apapun dalam suatu database transaction<\/em>, sementara istilah \u201ccommit<\/em>\u201d mengacu pada perubahan permanen yang sudah diterapkan pada suatu transaksi.<\/p>\n

    \u00a0<\/em><\/strong><\/p>\n

    Transaction Properties<\/em><\/strong><\/p>\n

    Setiap individual transaction <\/em>(transaksi individu \u2500 satu unit proses dalam database<\/em>) harus memiliki beberapa properti yang menjamin keamanan data dalam database. <\/em>Properti ini disingkat dengan ACID; atomicity, consistency, isolation, <\/em>dan durability. <\/em>Berikut adalah penjelasan dari masing-masing properties.<\/em><\/p>\n

    \"\"<\/p>\n

      \n
    1. Atomicity<\/em><\/li>\n<\/ol>\n

      Atomicity <\/em>memastikan bahwa semua operasi dalam suatu transaksi harus berjalan sepenuhnya atau tidak sama sekali. Jika ada bagian dari transaksi yang mengalami kegagalan, maka seluruh transaksi akan dibatalkan. Misalnya, jika transaksi A memiliki empat perintah SQL (bahasa pemograman yang digunakan dalam Database Management System <\/em>atau DBMS untuk mengakses dan menjalankan berbagai operasi dalam database<\/em>), maka keempat perintah tersebut harus berhasil dijalankan semuanya. Jika ada salah satu saja yang gagal, maka keseluruhan transaksi akan dibatalkan. Untuk kasus yang lebih relevan, seperti contoh transaksi dari rekening A ke B yang telah dijelaskan sebelumnya, jika terjadi gangguan saat pembayaran (misalnya server down <\/em>atau jaringan terputus), transaksi akan langsung dibatalkan sehingga tidak ada pembaruan saldo di kedua rekening.<\/p>\n

        \n
      1. Consistency<\/em><\/li>\n<\/ol>\n

        Consistency <\/em>menjamin bahwa database <\/em>selalu dalam keadaan konsisten sebelum dan sesudah transaksi. Jika ada bagian dari transaksi yang melanggar integrity rule <\/em>(aturan yang diciptakan untuk memastikan keakuratan, konsistensi, dan validitas data di dalam suatu database<\/em>), maka seluruh transaksi akan dibatalkan supaya data yang disimpan tetap valid dan akurat. Misalnya, aturan sistem database<\/em> menyatakan bahwa stok barang tidak boleh bernilai negatif. Jika seorang pelanggan ingin membeli barang X dengan jumlah yang lebih banyak dari stok yang tersedia (anggap saja stok yang tersedia 1, tetapi pelanggan ingin membeli 2 buah barang X), maka transaksi akan dibatalkan supaya database <\/em>tetap konsisten (tidak ada stok yang bernilai negatif).<\/p>\n

          \n
        1. Isolation<\/em><\/li>\n<\/ol>\n

          Isolation<\/em> memastikan bahwa data yang digunakan dalam suatu transaksi tidak bisa diakses oleh transaksi lain sebelum transaksi tersebut selesai dijalankan. Misalnya, bayangkan ada dua penumpang (sebut saja A dan B) yang sama-sama ingin memesan kursi terakhir pada pesawat X melalui aplikasi pesan tiket pesawat. Jika penumpang A terlebih dahulu menekan tombol pemesanan, maka sistem akan \u201cmengunci\u201d data kursi tersebut untuk transaksi A hingga transaksi tersebut selesai. Selama proses ini berlangsung, penumpang B yang juga ingin memesan kursi yang sama harus menunggu hingga transaksi A selesai. Jika transaksi A berhasil, maka kursi akan diperbarui menjadi penuh sehingga transaksi B akan dibatalkan. Namun, jika transaksi A gagal (misalnya karena pembayaran tidak berhasil), maka penumpang B bisa melanjutkan pemesanannya.<\/p>\n

            \n
          1. Durability<\/em><\/li>\n<\/ol>\n

            Durability <\/em>menjamin bahwa data yang sudah difinalisasi di database <\/em>tidak akan hilang meskipun terjadi kegagalan sistem atau pemadaman listrik. Jadi, data yang sudah disimpan akan tetap ada secara permanen. Misalnya, jika penumpang telah berhasil membeli tiket pesawat melalui aplikasi online<\/em>, maka transaksi yang dilakukan penumpang tersebut akan di-commit <\/em>(difinalisasi) dan jumlah tiket yang masih tersedia di sistem database <\/em>akan berkurang. Jika di kemudian hari ada gangguan listrik atau server down<\/em>, perubahan pada database <\/em>(jumlah tiket yang sudah dikurangi pembelian tersebut) tetap akan disimpan dan tidak akan hilang.<\/p>\n

            Sebagai tambahan, jika ingin mengeksekusi multiple transaction<\/em> (banyak transaksi yang berjalan secara bersamaan), Database Management System <\/em>(DBMS \u2500 \u201cotak\u201d dari database<\/em>, memungkinkan user <\/em>untuk mengakses dan menjalankan berbagai operasi dalam database<\/em>) harus mengatur jalannya transaksi agar tidak terjadi konflik. Proses eksekusi transaksi ini harus menunjukkan serializability, <\/em>yang berfungsi dalam memastikan bahwa hasil akhirnya sama seperti jika transaksi dijalankan satu per satu secara berurutan.<\/p>\n

            Contoh penerapannya, misalkan ada dua calon penumpang (sebut saja A dan B) yang ingin memesan tiket pesawat yang tersisa 2 kursi pada waktu bersamaan. Transaksi A pertama-tama membaca jumlah kursi yang tersedia (2 kursi), memesan 1 kursi, lalu memperbarui jumlah kursi (menjadi sisa 1 kursi). Sementara itu, transaksi B juga membaca jumlah kursi yang tersedia (2 kursi) sebelum transaksi A selesai, kemudian memesan 1 kursi dan memperbarui jumlah kursi pesawat hingga menjadi 1 kursi. Jika DBMS tidak menerapkan serializability<\/em>, kedua transaksi tersebut akan menghasilkan data yang tidak konsisten karena seharusnya kursi sudah tidak tersedia lagi (sisa 0). Namun, dengan serializability<\/em>, DBMS akan mengeksekusi kedua transaksi ini hingga seolah-olah dilakukan secara berurutan. Jadi, transaksi A akan diselesaikan terlebih dahulu sehingga jumlah kursi diperbarui menjadi 1 kursi, barulah transaksi B dijalankan dengan membaca data paling baru, memesan kursi terakhir, dan memperbarui jumlah kursi menjadi 0 kursi.<\/p>\n

            \u00a0<\/em><\/p>\n

            Referensi<\/strong><\/p>\n

            Coronel, C. & Morris, S. (2023). Database Systems Design, Implementation, and Management (Eleventh Edition). Cengage Learning.<\/p>\n

            Fauna. (2021). What is a Database Transaction? Diakses dari https:\/\/fauna.com\/blog\/database-transaction<\/a> pada tanggal 5 Maret 2025.<\/p>\n

            Aditya. (2021). Mengenal Transaksi Database & ACID. Diakses dari https:\/\/subreza.medium.com\/mengenal-transaksi-database-acid-b1a9c187ad62<\/a> pada tanggal 6 Maret 2025.<\/p>\n

            [GAMBAR ILUSTRASI] https:\/\/www.scylladb.com\/wp-content\/uploads\/acid-diagram.png<\/a><\/p>\n

             <\/p>\n

            Editor : Edi Purnomo Putra<\/p>\n","protected":false},"excerpt":{"rendered":"

            Seperti yang kita tahu, database merupakan kumpulan data yang terorganisir dan saling berhubungan dalam suatu sistem komputer. Di dalam suatu database yang besar (seperti database perusahaan yang menyimpan data transaksi ribuan pelanggan), jutaan request per-detik bisa diproses di dalam database. Banyaknya request yang masuk seringkali \u201cmenyentuh\u201d komponen yang sama di database, sehingga bisa menimbulkan permasalahan […]<\/p>\n","protected":false},"author":11,"featured_media":348,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-346","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles"],"_links":{"self":[{"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/posts\/346","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/users\/11"}],"replies":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/comments?post=346"}],"version-history":[{"count":6,"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/posts\/346\/revisions"}],"predecessor-version":[{"id":354,"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/posts\/346\/revisions\/354"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/media\/348"}],"wp:attachment":[{"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/media?parent=346"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/categories?post=346"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/binus.ac.id\/semarang\/information-systems\/wp-json\/wp\/v2\/tags?post=346"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}