Presentasi Keamanan Basis Data “Transaction Management”

Presentasi berjudul: "Presentasi Keamanan Basis Data “Transaction Management”"— Transcript presentasi:

1 Presentasi Keamanan Basis Data “Transaction Management”
Anggota Kelompok : Theodorin Hanna V.K ( ) Nur Indani Sari ( ) Pandu Wibowo ( ) Bimo Santoso Aji ( )

2 Transaksi Suatu tindakan, atau serangkaian tindakan yang dilakukan oleh single user atau program aplikasi, dengan membaca atau memperbarui isi database. Sebuah unit logis yang bekerja pada database. Mungkin seluruh program,bagian dari program, biasanya berupa perintah tunggal (misalnya, perintah SQL INSERT atau UPDATE), dan mungkin melibatkan sejumlah operasi pada database.

3 Transaksi “Sebuah unit eksekusi program yang mengakses
dan mengubah beberapa item data dalam Database”

4 Dalam konteks BD, pelaksanaan suatu program aplikasi bisa dianggap sebagai satu atau lebih transaksi dengan non-database pengolahan yang ada. Untuk menggambarkan konsep transaksi, kita lihat contoh dua relasi dari DreamHome rental database yang ditampilkan pada Gambar berikut ini:

5

6 Sebuah transaksi sederhana yg terjadi pd database ini adalah untuk memperbarui gaji Staf yang definisikan sebagai x. Pada tingkat tinggi, kita bisa menuliskan transaksi ini seperti yang ditunjukkan pada Gambar 20.1 (a). Dalam gambar ini kita ditunjukkan database yang membaca atau menulis operasi pada data barang yang diinisialkan dengan x sebagai read (x) atau write (x).

7 Dalam contoh ini, kita memiliki transaksi yang terdiri dari dua operasi database (membaca dan menampilkan) dan sebuah operasi non-database Contohnya (gaji = gaji * 1.1).

8 Ada lagi transaksi yang lebih rumit, yakni transaksi untuk menghapus staf dengan staf yang diidentifikasi sebagai x, seperti yang ditunjukkan pada Gambar 20.1 (b). Dalam kasus ini sebaik mungkin kita harus menghapus tuple dalam relasi staff, kita juga harus menemukan semua tuple PropertyForRent yang dikelola staff mengalihkannya kestaf yang berbeda, yaitu newStaffNo.

9 Jika semua update-an tidak dibuat maka, semua informasi yg dibutuhkan di DB akan hilang dan database menjadi tidak konsisten. properti akan dikelola oleh anggota staff yang tidak lagi ada dalam database. (mau pake Staff No tp Staff No mau dihapus).

10 Sebuah transaksi harus selalu mengubah database dari satu kondisi ke kondisi konsisten lain, walaupun transaksi itu menerima konsistensi yang mungkin dilanggar ketika transaksi sedang berlangsung. (jadi bisa menggunakan cara lain, gak hasus pake yg di gambar 20(b).)

11 Sebagai contoh, selama transaksi pada Gambar 20
Sebagai contoh, selama transaksi pada Gambar 20.1 (b), mungkin ada saat tertentu ketika salah satu tuple PropertyForRent berisi nilai newStaffNo baru dan yg lain masih mengandung yang lama, yakni x. Tapi pada akhir transaksi, semua tuple yang diperlukan harus punya newStaffNo nilai. jika transaksi tidak berhasi dieksekusi, else nya transaksi akan dibatalkan. (mbuh carane pie tapi harus jadi newstaffno value yg baru)

12 Jika transaksi dibatalkan, database harus dikembalikan ke keadaan awal sebelum transaksi dimulai. Bagai transaksi yang terguling kembali atau traksaksi yang dibatalkan. Dan transaksi yang sudah di commit gak bisa dikembalikan lagi. Jika kita memutuskan bahwa traksaksi yang udah di commit salah, kita harus melakukan transaksi lain yang serupa untuk membalikkan efek. (seperti yang kita bahas dalam Bagian ).

13 Contoh mendelete file, ada yg read only, ada yg langsung ke delete

14 DBMS tidak memiliki cara pasti untuk mengetahui update-an untuk membentuk transaksi logis tunggal, karena harus menyediakan metode yg memungkinkan pengguna untuk menunjukkan batas-batas transaksi yang dilalukan. kekurangannya

15 TRANSAKSI BERDASARKAN SIFAT DATA
Partially Commited Pada titik ini dapat ditemukan bahwa transaksi telah melanggar serializability (lihat Bagian ) atau telah melanggar suatu kendala keutuhan data dan efeknya transaksi harus dibatalkan.

16 Failed terjadi jika transaksi tidak dapat dilakukan atau transaksi dibatalkan, mungkin karena pengguna membatalkan transaksi untuk memastikan serializability.

17 Dalam Konsep transaksi di database harus di penuhi empat sifat database agar integritas database tetap terjaga. Adapun keempat sifat tersebut adalah : Atomicity: Setiap transaksi harus dijamin untuk dapat sukses dalam melakukan aksinya atau jika gagal , maka tidak berpengaruh apapun terhadap database. Consistency: Setiap transaksi adalah sebuah aksi kombinasi secara logikal dari sebuah state database yang konsisten ke state yang lain dengan tetap menjaga kekonsisten-an database tersebut.

18 Isolation: Meskipun ada beberapa transaksi yang berlangsung bersamaan, masing-masing transaksi tidak boleh mengetahui transaksi lain yang sedang berlangsung. Hasil transaksi sementara harus disembunyikan dari transaksi lain yang sedang berlangsung . (level transparansi transaksi dapat di set). Durability: Setelah sebuah transaksi sukses dilakukan, perubahan-perubahan yang dibuatnya terhadap database bersifat permanen, bahkan jika terjadi kegagalan sistem sekalipun.

19 Database Arsitektur

20 Concurrency Control Salah satu tujuan utama dalam mengembangkan database adalah untuk memungkinkan banyak pengguna mengakses data yang sama secara bersamaan.

21 Concurrency Control Akses bersamaan akan menjadi lebih mudah jika semua pengguna hanya dapat membaca data saja. Dengan demikian tidak akan memberikan kesempatan kepada pihak tertentu untuk ‘mengganggu’ orang lain.

22 Concurrency Control Gangguan akan terjadi jika dua atau lebih user mengakses database secara simultan dan sedikitnya melakukan suatu perubahan (update), maka dapat menyebabkan data tidak konsisten.

23 Concurrency Control Terdapat tiga masalah potensial yang disebabkan oleh concurrency, yaitu: Masalah kehilangan modifikasi (Lost Updates Problem) Masalah ketergantungan yang tidak terikat (Uncommitted Dependency Problem) Masalah analisa yang tidak konsisten (Inconsistent Analysis Problem)

24 Masalah Kehilangan Modifikasi (Lost Updates Problem)
Masalah ini timbul jika dua transaksi mengakses item database yang sama yang mengakibatkan nilai dari database tersebut menjadi tidak benar.

25 Masalah Kehilangan Modifikasi (Lost Updates Problem)
TRANSAKSI A WAKTU TRANSAKSI B = Baca R Modifikasi R ↓ t1 t2 t3 T4 Transaksi A membaca data pada waktu T1. Dalam proses membacanya, di waktu T2, Transaksi B juga melakukan proses pembacaan. Kemudian oleh Transaksi A, dilakukan modifikasi saat waktu T3 dimana Transaksi B sedang dalam proses membaca. Dan pada waktu T4, Transaksi B melakukan modifikasi dimana pada Transaksi A sudah selesai. Maka hasil modifikasi oleh Transaksi A dan Transaksi B akan hilang karena dilakukan saat data di proses secara bersamaan.

26 Masalah Modifikasi Sementara (Uncommitted Dependency Problem)
Masalah ini timbul jika transaksi membaca suatu record yang sudah dimodifikasi oleh transaksi lain tetapi belum terselesaikan (uncommited), terdapat kemungkinan kalau transaksi tersebut dibatalkan (rollback).

27 Masalah Modifikasi Sementara (Uncommitted Dependency Problem)
Nilai saldo menjadi tidak benar disebabkan terjadi RollBack pada T7 yang membatalkan transaksi sebelumnya (T6), sehingga saldo seharusnya tetap

28 Masalah Modifikasi Sementara (Uncommitted Dependency Problem)
Transaksi membaca nilai yang ditulis oleh transaksi yang telah kemudian dibatalkan. Nilai ini menghilang dari database pada abort, dan tidak seharusnya dibaca oleh setiap transaksi ("membaca kotor"). Pembacaan transaksi diakhiri dengan hasil yang salah.

29 Kedua masalah dalam contoh ini berkonsentrasi pada transaksi yang memperbarui database dan gangguan mereka dapat merusak database. Namun, transaksi yang hanya membaca database juga dapat menghasilkan hasil yang tidak akurat jika mereka diizinkan untuk membaca hasil parsial dari transaksi yang tidak lengkap yang bersamaan memperbarui database.

30 Masalah Analisa yang Tidak Konsisten (Inconsistent Analysis Problem)
Masalah ini timbul jika sebuah transaksi membaca suatu nilai tetapi transaksi yang kedua mengupdate beberapa nilai tersebut selama eksekusi transaksi pertama

31 Masalah Analisa yang Tidak Konsisten (Inconsistent Analysis Problem)

32 Contoh transaksi T6 menjumlahkan variable balx (£100), baly (£50), dan balz (£25). Pada saat yang hampir bersamaan transaksi T5 memindahkan £10 dari balx ke balz, sehingga transaksi T6 mendapatkan hasil akhir yang salah (yaitu kelebihan £10). Masalah tersebut dapat dihindari dengan mencegah transaksi T6 membaca balx dan balz sebelum transaksi T5 lengkap di-update.

33 Masalah lainnya dapat terjadi jika transaksi T membaca ulang item data yang sebelumnya telah dibaca. Tetapi, di samping itu transaksi yang lainnya telah mengubahnya. Dengan demikian, T menerima dua nilai yang berbeda untuk item data yang sama.

34 Hal ini disebut dengan nonrepeatable (or fuzzy) read
Hal ini disebut dengan nonrepeatable (or fuzzy) read. Masalah serupa dapat terjadi jika transaksi T mengeksekusi query yang mengambil satu set tupel dari relasi yang memenuhi predikat tertentu, mengeksekusi kembali query di lain waktu, tetapi menemukan bahwa set yang diambil berisi tupel (phantom) tambahan yang telah dimasukkan oleh transaksi lain untuk sementara. Hal ini seringkali disebut sebagai read phantom.

35 Serializability dan Recoverability
Tujuan protokol concurrency control adalah untuk menjadwalkan transaksi sedemikian rupa sehingga dapat menghindar dari berbagai gangguan. Satu solusi yang jelas adalah mengijinkan hanya satu transaksi yang berjalan dalam satu waktu. Satu transaksi berstatus commit sebelum transaksi berikutnya diijinkan mulai.

36 Namun, tujuan dari DBMS multi user juga untuk memaksimalkan derajat concurrency atau paralelisme dalam sebuah sistem, sehingga transaksi yang dapat berjalan tanpa mengganggu satu sama lain dapat berjalan secara paralel. Dalam bagian ini, kita memeriksa serializability sebagai sebuah cara untuk membantu mengidentifikasi eksekusi transaksi tersebut yang dijamin untuk memastikan konsistensi.

37 Schedule Schedule adalah sebuah urutan dari operasi-operasi oleh satu set transaksi yang jalan bersamaan yang menjaga urutan operasi pada setiap transaksi individual. Sebuah transaksi mencakup sebuah urutan operasi yang terdiri dari tindakan baca dan/atau tulis pada database, diikuti oleh sebuah tindakan commit atau abort. Sebuah schedule S terdiri dari sebuah urutan operasi dari sekumpulan n transaksi T1, T2, … Tn, bergantung pada constraint yang dilindungi oleh urutan operasi untuk setiap transaksi pada scheduletersebut. Jadi, untuk setiap transaksi Ti pada schedule S, urutan operasi pada Ti harus sama dengan schedule S. 

38 Serial Schedule adalah sebuah schedule di mana operasi dari setiap transaksi dijalankan secara berurutan tanpa adanya tarnsaksi yang mengganggu transaksi lainnya. NonSerial Schedule adalah sebuah schedule di mana operasi-operasi dari satu set concurrent transactions mengalami interleaved. Pada sebuah serial schedule, transaksi dijalankan pada serial order. Lalu, pada eksekusi serial tidak ada interferensi antara transaksi

39 Tujuan serializibility adalah untuk menemukan non serial schedule yang mengijinkan transaksi untuk berjalan secara bersamaan tanpa mengganggu satu sama lain, dan kemudian memproduksi sebuah state database yang dapat diproduksi oleh sebuah eksekusi serial. Untuk mencegah inkonsistensi dari transaksi yang mengganggu satu sama lain, penting untuk menjamin serializability dari transaksi yang jalan bersamaan.

40 Pada serializability, urutan operasi baca dan tulis itu penting
Pada serializability, urutan operasi baca dan tulis itu penting. Berikut ini hal – hal yang perlu diperhatikan: ·        Jika dua transaksi hanya membaca satu item data yang sama, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting. ·         Jika dua transaksi melakukan operasi membaca ataupun menulis pada item data yang berbeda, dua transaksi tersebut tidak mengalami konflik dan urutan menjadi tidak penting. ·      Jika satu transaksi menulis sebuah item data dan transaksi lain baik membaca ataupun menulis pada item data yang sama, maka urutan eksekusi itu menjadi penting.

41 Keterangan Gambar : (a) nonserial schedule A (b) nonserial schedule B (c) serial schedule C, ekuivalen dengan A dan B Schedule Cadalah sebuah schedule serial dan karena A dan B ekuivalen dengan C, maka A dan B adalah serializable schedule. Recoverable schedule adalah sebuah schedule di mana, untuk setiap transaksi Ti dan Tj, jika Tj membaca sebuah item data yang sebelumnya ditulis oleh Ti, kemudian operasi commit dari Ti mendahului operasi commit Tj.

42 Teknik Concurrency Control
Ada dua teknik concurrency control utama yang mengijinkan transaksi untuk berjalan dengan aman dalam subjek paralel untuk constraint tertentu, yaitu locking dan metode timestamp tertentu. Locking dan timestamping adalah pendekatan konservatif karena mereka menyebabkan transaksi ditunda dalam kasus mereka konflik dengan transaksi lain pada beberapa waktu di masa yang akan datang. Metode optimistik, didasarkan pada premis bahwa konflik itu jarang ditemui, jadi mereka mengijinkan transaksi untuk lanjut tidak tersinkronisasi dan hanya mengecek konflik di bagian akhir, ketika transaksi melakukan operasi commit.

43 Terima Kasih