BAB 2 LANDASAN TEORI

Transkripsi

1 10 BAB 2 LANDASAN TEORI 2.1 Database Database adalah sekumpulan data yang terhubung secara logikal, dan deskripsi dari data tersebut, yang dapat digunakan oleh banyak user dan dibentuk untuk dapat menghasilkan informasi yang dibutuhkan oleh organisasi (Connolly, 2005, p15). Database adalah sekumpulan data yang tetap (persistent data) yang digunakan oleh sistem aplikasi dari perusahaan (Date, 2000, p10). Database merupakan tempat penyimpanan data yang dapat berukuran besar dan dapat digunakan secara bersama-sama oleh banyak departemen dan user. Sebagai pengganti file-file yang tidak terhubung dan memiliki banyak duplikasi, data-data pada database dibuat terintegrasi dengan jumlah duplikasi yang lebih minimum. Database tidak hanya berisi data operasional organisasi, namun juga berisi deskripsi dari data yang disebut sebagai system catalog atau data dictionary atau meta data (data tentang data) (Connolly, 2005, p15). 2.2 Database Management System (DBMS) DBMS adalah sebuah sistem perangkat lunak yang memungkinkan user untuk mengidentifikasikan, membuat, memelihara dan mengontrol akses ke database (Connolly, 2005, p16). DBMS merupakan perangkat lunak yang berinteraksi dengan program aplikasi yang digunakan user dan database. DBMS menyediakan beberapa fasilitas, yaitu:

2 11 DBMS mengijinkan user untuk mendefinisikan database melalui Data Definition Language (DDL). DBMS mengijinkan user untuk melakukan insert, update, delete, dan retrieve terhadap data dari database melalui Data Manipulation Language (DML). DBMS menyediakan pengaksesan terkendali terhadap database, yaitu: Security system yang berfungsi untuk mencegah user yang tidak berhak mengakses database. Integrity system yang berfungsi untuk memelihara sifat konsistensi terhadap data yang disimpan. Concurrency control system yang berfungsi untuk mengatur akses secara bersamaan pada database. Recovery control system yang berfungsi untuk melakukan restoring data ke kondisi konsisten sebelumnya jika terjadi kegagalan pada perangkat keras atau perangkat lunak. User accessible catalog yang berisi deskripsi-deskripsi dari data yang terdapat pada database (Connolly, 2005, p16) Komponen DBMS DBMS memiliki lima komponen utama (Connolly, 2005, p18), yaitu : Perangkat keras (Hardware) DBMS dan aplikasi membutuhkan perangkat keras untuk melakukan proses running. Perangkat keras yang digunakan dapat bervariasi mulai

3 12 dari personal computer (PC), mainframe tunggal, sampai komputerkomputer yang menggunakan jaringan. Perangkat lunak (Software) Komponen perangkat lunak terdiri dari perangkat lunak DBMS itu sendiri dan program aplikasi, bersama-sama dengan sistem operasi, termasuk perangkat lunak jaringan jika DBMS digunakan melalui jaringan. Biasanya program aplikasi ditulis dengan bahasa pemrograman generasi ketiga (3GL) seperti C, C++, Java, VB, COBOL, Fortran, Ada, atau Pascal, atau menggunakan bahasa pemrograman generasi keempat (4GL) seperti SQL digabungkan dengan bahasa pemrograman generasi ketiga. Data Komponen terpenting dalam lingkungan DBMS adalah data. Data berperan sebagai jembatan antara komponen mesin dan manusia. Database terdiri dari data operasional dan meta-data (data tentang data itu sendiri). Prosedur Prosedur mengacu pada bentuk instruksi dan aturan aturan yang menentukan desain dan kegunaan database. Para user sistem dan staff yang mengatur database membutuhkan prosedur terdokumentasi yang berisi aturan bagaimana menjalankan sistem. People People merupakan orang-orang yang terkait dengan sistem.

4 Advantages and Disadvantages of DBMSs Dibandingkan dengan file-based approach, DBMS memiliki jauh lebih banyak keuntungan. Berikut ini tabel keuntungan dan kerugian penggunaan DBMS. Advantages Control of data redundancy Data consistency More information from the same amount Disadvantages Complexity Size Cost of DBMSs of data Sharing of data Improved data integrity Improved security Enforcement of standards Additional hardware cost Cost of conversion Performance Higher impact of a failure Economy of scale Balance of conflicting requirements Improved data accessibility and responsiveness Increased productivity Improved maintenance through data independence Increased concurrency Improved backup and recovery services Tabel 2. 1 Advantages and disadvantages of DBMSs Sumber : Connoly, 2005, p26

5 Database Model Relasional Database model relasional adalah kumpulan dari relations yang telah mengalami proses normalisasi dan memiliki nama relation yang berbeda (Connolly, 2005, p74). Dalam terminologi model relasional, dikenal istilah-istilah seperti relation, attribute, domain, tuple, degree, dan cardinality. Relation adalah sebuah tabel yang terdiri atas kolom-kolom dan baris-baris. Attribute adalah kolom yang terdapat dalam sebuah tabel. Domain adalah sekumpulan nilai yang diperbolehkan untuk satu atau banyak atribut. Tuple adalah sebuah baris atau record dalam sebuah tabel. Degree adalah jumlah attribute yang terdapat dalam sebuah tabel. Cardinality adalah jumlah record yang terdapat dalam sebuah tabel (Connolly, 2005, p72). Dalam database model relasional tidak boleh terdapat duplicate tuples dalam sebuah tabel. Karena itu harus ada satu atau lebih attribute yang dapat mengidentifikasi tuple secara unik. Terminologi yang digunakan dalam hal ini disebut sebagai relational keys. Superkey adalah sebuah attribute atau sekumpulan attribute yang mengidentifikasikan sebuah tuple secara unik didalam sebuah tabel. Namun superkey dapat berisi attribute yang mungkin saja tidak dibutuhkan untuk mengidentifikasikan sebuah tuple secara unik. Candidate key adalah sebuah superkey yang memiliki sifat uniqueness dan irreducibility. Primary key adalah candidate key yang terpilih untuk mengidentifikasikan tuple secara unik di dalam sebuah tabel. Alternate key adalah candidate key yang tidak terpilih menjadi primary key. Foreign key adalah sebuah attribute atau sekumpulan attribute

6 15 didalam sebuah tabel yang terhubung dengan candidate key pada tabel lain (Connolly, 2005, p78). Sebuah relation dalam database model relasional memiliki properti sebagai berikut: Setiap relation memiliki nama yang berbeda dengan relation lainnya dalam sebuah relational schema. Setiap cell dari sebuah relation hanya berisi sebuah nilai tunggal. Setiap attribute dalam sebuah relation memiliki nama yang berbeda. Nilai dari sebuah attribute berasal dari domain yang sama. Tidak mempunyai duplicate tuple. Urutan attribute dari kiri ke kanan tidak memiliki makna tertentu. Urutan tuple dari atas ke bawah tidak memiliki makna tertentu secara teori. Namun, secara teknis dapat memiliki pengaruh dalam efisiensi proses pengaksesan tuple. (Connolly, 2005, p77). Dalam terminologi model relasional, relation dapat juga disebut sebagai table atau file. Tuple dapat juga disebut sebagai row atau record. Attribute dapat juga disebut sebagai column atau field (Connolly, 2005, p74).

7 Concurrency Control Kebutuhan Akan Concurrency Control Tujuan utama dalam pengembangan database adalah membuat banyak user bisa mengakses data secara bersamaan. Pengaksesan data ini tidak bermasalah jika semua user hanya membaca data dan mereka tidak mengganggu satu sama lain. Tapi ketika dua user atau lebih mengakses database secara bersamaan dan salah satu melakukan perubahan terhadap data, maka hal ini akan dapat menimbulkan adanya data yang tidak konsisten (inconsistency data). Untuk mengatasi adanya kemungkinan inconsistency data, maka dibutuhkan adanya suatu mekanisme yang mengatur jalannya transaksi yang mengakses data yang sama tersebut. Mekanisme ini dikenal dengan istilah concurrency control. Concurrency control adalah proses pengaturan operasi-operasi dalam banyak transaksi yang berjalan secara simultan pada database tanpa mengganggu operasi pada transaksi lainnya sehingga dapat menghasilkan data yang konsisten (Connolly, 2005, p577). Tiga contoh masalah penting yang disebabkan oleh concurrency : - Masalah lost update - Masalah uncommitted dependency - Masalah inconsistent analysis Untuk mengilustrasikan masalah ini, digunakan sebuah relation rekening staff bank sederhana yang mengandung saldo rekening bal x, bal y,

8 17 dan bal z. Dalam konteks ini, digunakan transaksi sebagai unit concurrency control Masalah Lost Update Time T 1 T 2 bal x T 1 begin_transaction 100 T 2 Begin_transaction read(bal x ) 100 T 3 read(bal x ) bal x = bal x T 4 bal x = bal x - 10 write(bal x ) 200 T 5 write(bal x ) commit 90 T 6 commit 90 Tabel 2. 2 Masalah lost update Sumber : Connoly, 2005, p578 Penjelasan : Transaksi T 1 dan T 2 mulai pada waktu yang hampir bersamaan, dan keduanya membaca saldo bal x sebesar $100. T 2 menambah bal x $100 menjadi $200 dan menyimpan hasil perubahannya dalam database. Di sisi lain, transaksi T 1 mengurangi copy dari bal x $10 menjadi $90 dan menyimpan nilai ini dalam database, menimpa hasil update sebelumnya

9 18 dan akhirnya menghilangkan $100 yang telah ditambahkan sebelumnya ke dalam saldo. Kehilangan update transaksi T 2 dapat dihindari dengan mencegah T 1 membaca nilai dari bal x sampai update T 2 telah selesai Masalah Uncommitted Dependency (Dirty Read) Time T 3 T 4 bal x T 1 begin_transaction 100 T 2 read(bal x ) 100 T 3 bal x = bal x T 4 begin_transaction write(bal x ) 200 T 5 read(bal x ) 200 T 6 bal x = bal x - 10 rollback 100 T 7 write(bal x ) 190 T 8 Commit 190 Tabel 2. 3 Masalah uncommitted dependency (dirty read) Sumber : Connoly, 2005, p578 Penjelasan: Transaksi T 4 mengubah bal x menjadi $200 namun T 4 membatalkan transaksi sehingga bal x harus dikembalikan ke nilai asalnya, yaitu $100. Namun, pada waktu itu, transaksi T 3 telah membaca nilai baru bal x ($200) dan menggunakan nilai ini sebagai dasar pengurangan $10, sehingga memberikan saldo yang keliru sebesar $190, yang seharusnya adalah $90.

10 19 Nilai bal x yang dibaca T 3 disebut dirty data, yang berasal dari nama alternatifnya, yaitu masalah dirty read. Bal x disebut sebagai dirty data karena nilainya didapatkan dari transaksi yang belum selesai dan belum commit (Elmasri, 2000, p635). Alasan rollback ini tidaklah penting. Mungkin masalahnya adalah transaksinya gagal (error), mungkin mengurangi rekening yang salah. Efeknya adalah asumsi T 3 yang menganggap update T 4 telah berhasil dijalankan, meskipun selanjutnya perubahannya dibatalkan. Masalah ini dapat dihindari dengan mencegah T 3 membaca bal x sampai keputusan telah dibuat, yaitu commit atau abort transaksi T 4. Dua masalah di atas mengkonsentrasikan pada transaksi yang mengubah database dan campur tangan mereka bisa membuat database menjadi corrupt. Namun, transaksi yang hanya membaca database bisa juga memberikan hasil yang tidak akurat jika mereka diijinkan untuk membaca hasil bagian dari transaksi yang belum selesai yang secara bersamaan membaca dan menulis database. Contohnya dijelaskan pada masalah inconsistent analysis Masalah Inconsistent Analysis Time T 5 T 6 bal x bal y bal z sum t 1 begin_tran t 2 begin_tran Sum= t 3 read(bal x ) Read(bal x )

11 20 t 4 bal x = bal x - 10 Sum=sum+bal x t 5 write(bal x ) Read(bal y ) t 6 read(bal z ) sum=sum+bal y t 7 bal z =bal z t 8 write(bal z ) t 9 commit read(bal z ) t 10 sum=sum+bal z t 11 commit Tabel 2. 4 Masalah inconsistent analysis Sumber : Connoly, 2005, p579 Penjelasan: Masalah inconsistent analysis muncul ketika sebuah transaksi membaca beberapa nilai dari database tapi transaksi kedua mengubah beberapa darinya ketika eksekusi transaksi yang pertama. Contohnya, sebuah transaksi yang meringkas data pada sebuah database(contohnya, saldo total) akan mendapat hasil yang tidak akurat jika, ketika berjalan, transaksi lain sedang mengubah database. Pada contoh diatas, ringkasan transaksi T 6 sedang berjalan secara bersamaan dengan transaksi T 5. Transaksi T 6 sedang menjumlahkan saldo rekening x ($100), rekening y ($50), dan rekening z($25). Namun, di tengah jalan, transaksi T 5 telah mentransfer $10 dari bal x ke bal z, sehingga T 6 sekarang mempunyai hasil yang salah (lebih besar $10). Masalah ini dapat dihindari dengan mencegah

12 21 transaksi T 6 membaca bal x dan bal z sampai setelah transaksi T 5 selesai mengubah nilai bal x dan bal z pada database Serializability dan Recoverability Tujuan protokol concurrency control adalah untuk menjadwalkan transaksi sedemikian rupa sehingga dapat terhindar dari berbagai gangguan, dan juga mencegah tipe-tipe masalah yang digambarkan pada sesi sebelumnya. Satu solusi yang jelas adalah mengijinkan hanya satu transaksi yang berjalan dalam satu waktu. Satu transaksi berstatus commit sebelum transaksi berikutnya diijinkan mulai. 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. Contohnya, transaksi yang mengakses bagian berbeda pada database dapat dijadwalkan bersama tanpa gangguan. Dalam bagian ini, kita memeriksa serializability sebagai sebuah cara untuk membantu mengidentifikasi eksekusi transaksi tersebut yang dijamin untuk memastikan konsistensi. Pertama, akan dijelaskan beberapa definisi Serializability Schedule adalah sebuah urutan dari operasi-operasi oleh satu set transaksi yang jalan bersamaan yang menjaga urutan operasi pada setiap transaksi individual (Connolly, 2005, p580).

13 22 Sebuah transaksi mencakup sebuah urutan operasi yang terdiri dari tindakan membaca dan/atau menulis pada database, diikuti oleh sebuah tindakan commit atau abort. Sebuah schedule S yang terdiri dari sebuah urutan operasi dari sekumpulan n transaksi T 1, T 2, T n, bergantung pada constraint dimana urutan operasi untuk setiap transaksi dilindungi di dalam schedule tersebut. Jadi, untuk setiap transaksi T i pada schedule S, urutan operasi pada T i harus sama dengan schedule S. Serial Schedule adalah sebuah schedule di mana operasi dari setiap transaksi dijalankan secara berurutan tanpa adanya interleaved operations dari transaksi lainnya (Connolly, 2005, p580). Nonserial Schedule adalah sebuah schedule di mana operasi-operasi dari satu set concurrent transactions mengalami interleaved (Connolly, 2005, p580). Pada sebuah serial schedule, transaksi dijalankan pada urutan tertentu. Contohnya, jika kita mempunyai dua transaksi T 1 dan T 2, serial order akan berupa T 1 diikuti oleh T 2, atau T 2 diikuti oleh T 1. Pada eksekusi serial tidak ada interferensi antara transaksi, karena hanya satu transaksi yang berjalan pada satu waktu. Masalah lost update, masalah uncommited dependency (dirty read), dan masalah inconsistent analysis terjadi karena kurangnya pengaturan masalah concurrency, yang menyebabkan database menghasilkan data yang tidak konsisten. Eksekusi serial mencegah terjadinya masalah ini. Sebuah eksekusi serial tidak akan membuat database menjadi tidak konsisten.

14 23 Tujuan serializibility adalah untuk menemukan nonserial schedule yang mengijinkan transaksi untuk berjalan secara bersamaan tanpa mengganggu satu sama lain, dan kemudian menghasilkan sebuah database state yang dapat diproduksi oleh sebuah eksekusi serial. Jika sekumpulan transaksi berjalan secara bersamaan, bisa dikatakan bahwa nonserial schedule adalah benar jika memproduksi hasil yang sama seperti beberapa eksekusi serial lainnya. Schedule seperti itu disebut serializable (Connolly, 2005, p581). Konsep serializability of schedules digunakan untuk mengidentifikasi apakah schedule adalah benar ketika eksekusi transaksi memiliki interleaving pada operasi di dalam schedule (Elmasri, 2000, p644). Untuk mencegah inkonsistensi dari transaksi yang mengganggu satu sama lain, penting untuk menjamin serializability dari transaksi yang jalan bersamaan. 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.

15 24 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. Anggap schedule S 1 yang ditunjukkan oleh tabel 2.5a mengandung operasi dari dua transaksi yang sedang berjalan secara bersamaan, yaitu T 7 dan T 8. Karena operasi tulis pada bal x di T 8 tidak konflik dengan operasi baca berikutnya pada bal y di T 7, urutan operasinya dapat diubah untuk memproduksi schedule yang ekuivalen (S 2 ) ditunjukkan oleh tabel 2.5b. Jika sekarang juga urutan dari operasi yang tidak konflik berikut diubah, akan diproduksi serial schedule yang ekuivalen (S 3 ) ditunjukkan oleh tabel 2.5c. Ubah urutan write(bal x ) di T 8 dengan write(bal y ) di T 7 Ubah urutan read(bal x ) di T 8 dengan read(bal y ) di T 7 Ubah urutan read(bal x ) di T 8 dengan write(bal y ) di T 7 (a) (b) (c) Time T 7 T 8 T 7 T 8 T 7 T 8 t 1 begin_tran begin_tran begin_tran t 2 read(bal x ) read(bal x ) read(bal x ) t 3 write(bal x ) write(bal x ) write(bal x ) t 4 begin_tran begin_tran read(bal y ) t 5 read(bal x ) read(bal x ) write(bal y )

16 25 t 6 write(bal x ) read(bal y ) commit t 7 read(bal x ) write(bal x ) begin_tran t 8 write(bal x ) write(bal y ) read(bal x ) t 9 commit Commit write(bal x ) t 10 read(bal y ) read(bal y ) read(bal y ) t 11 write(bal y ) write(bal y ) write(bal y ) t 12 commit commit commit Tabel 2. 5 Contoh serial dan nonserial schedule Sumber : Connoly,2005, p581 (a) nonserial schedule S 1 (b) nonserial schedule S 2 (c) serial shedule S 3, ekuivalen dengan S 1 dan S 2 Schedule S 3 adalah sebuah serial schedule dan karena S 1 dan S 2 ekuivalen dengan S 3, maka S 1 dan S 2 adalah serializable schedule. Tipe Serializability seperti ini disebut conflict serializability. Sebuah conflict serializable schedule mengurutkan operasi-operasi yang mengalami konflik dengan cara yang sama seperti eksekusi serial. Berdasarkan constrained write rule (bahwa sebuah transaksi melakukan perubahan terhadap sebuah data item berdasarkan pada nilai lamanya, yang pertama kali telah dibaca oleh transaksi), sebuah precedence atau serialization graph dapat digunakan untuk menguji conflict serializability. Untuk sebuah schedule S, sebuah precedence graph

17 26 adalah sebuah directed graph G = (N,E) yang berisi sekumpulan node N dan sekumpulan directed edges E yang dibangun seperti berikut : Buat sebuah node untuk setiap transaksi. Buat sebuah directed edge T i -> T j, jika T j membaca nilai dari sebuah item yang telah ditulis oleh T i. Buat sebuah directed edge T i -> T j, jika T j menulis nilai dari sebuah item yang telah dibaca oleh T i. Buat sebuah directed edge T i -> T j, jika T j menulis nilai dari sebuah item yang telah ditulis oleh T i. Jika sebuah edge T i -> T j sudah ada pada precedence graph untuk S, maka didalam serial schedule S yang ekivalen dengan S, T i harus muncul sebelum T j. Jika precedence graph berisi sebuah cycle, maka schedule itu menjadi tidak conflict serializable. Perhatikan dua transaksi pada tabel 2.6. Transaksi T 9 mentransfer 100 dari sebuah rekening dengan saldo bal x ke rekening lain dengan saldo bal y, sedangkan T 10 menambah saldo dari dua rekening ini sebesar 10%. Precedence graph untuk schedule ini seperti ditunjukkan oleh gambar 2.1, mempunyai sebuah cycle, jadi tidak bersifat conflict serializable. Time T 9 T 10 t 1 begin_transaction t 2 read ( bal x ) t 3 bal x = bal x + 100

18 27 t 4 write ( bal x ) begin_transaction t 5 read ( bal x ) t 6 bal x = bal x * 1.1 t 7 write ( bal x ) t 8 read ( bal y ) t 9 bal y = bal y * 1.1 t 10 write ( bal y ) t 11 read( bal y ) commit t 12 bal y = bal y 100 t 13 write ( bal y ) t 14 Commit Tabel 2. 6 Dua concurrent update transactions yang tidak conflict-serializable Sumber: Connoly,2005,p582 x T 9 T 10 y Gambar 2. 1 Precedence graph untuk tabel 2.6 menunjukkan sebuah cycle, jadi tidak conflict-serializable Sumber : Connoly, 2005, p583

19 28 Pada prakteknya, sebuah DBMS tidak menguji serializability dari sebuah schedule. Hal ini tidak praktis karena interleaving operasi-operasi dari transaksi-transaksi yang bersamaan ditentukan oleh sistem operasi. Sebaliknya, pendekatan yang digunakan adalah dengan menggunakan protokol yang dikenal untuk memproduksi serializable schedule Recoverability Serializability mengidentifikasikan schedule yang menjaga konsistensi database dengan asumsi tidak ada transaksi pada schedule yang gagal. Jika sebuah transaksi gagal, maka perlu dilakukan proses undo terhadap efek transaksi. Perhatikan lagi dua transaksi yang digambarkan pada tabel 2.6. Jika transaksi T 9 mengalami rollback, maka akan terjadi kesalahan data. T 10 membaca hasil perubahan data pada T 9 dan melakukan perubahan terhadap nilai bal x. Transaksi T 10 harus melakukan proses undo karena membaca nilai bal x dari transaksi T 9 yang ternyata mengalami rollback. Schedule seperti ini disebut nonrecoverable schedule yang harus dihindari. Recoverable schedule adalah sebuah schedule di mana, untuk setiap transaksi T i dan T j, jika T j membaca sebuah item data yang sebelumnya ditulis oleh T i, maka operasi commit dari T i mendahului operasi commit dari T j (Connolly, 2005, p587).

20 Metode Locking Locking adalah sebuah prosedur yang digunakan untuk mengendalikan akses bersamaan ke data. Ketika sebuah transaksi sedang mengakses database, sebuah lock mungkin menolak akses ke transaksi lain untuk mencegah hasil yang salah (Connolly, 2005, p587). Metode locking merupakan salah satu pendekatan yang banyak digunakan untuk menjamin serializability dari sejumlah concurrent transactions. Ada beberapa teknik locking yang sering digunakan. Dalam penulisan ini, akan dibahas metode locking dengan menggunakan shared lock dan exclusive lock. Sebuah transaksi harus meminta penggunaan shared lock dan exclusive lock sebelum melakukan akses membaca ataupun menulis terhadap database. Penggunaan lock ini adalah untuk menjaga konsistensi data didalam database. Jika sebuah transaksi mempunyai sebuah shared lock pada sebuah item data, transaksi dapat membaca item data tersebut tapi tidak dapat mengubahnya (Connolly, 2005, p588). Jika sebuah transaksi mempunyai sebuah exclusive lock pada sebuah item data, transaksi tersebut dapat membaca dan mengubah item data (Connolly, 2005, p588). Read Write Read Yes No Write No No Tabel 2. 7 Lock-compatibilitytables Sumber : Elmasri, 2000,p676

21 30 Lock digunakan dengan cara sebagai berikut : Transaksi apapun yang membutuhkan akses pada sebuah item data harus melakukan lock terhadap item tersebut, meminta shared lock untuk akses membaca saja atau sebuah exclusive lock untuk akses membaca dan menulis. Jika item belum dikunci oleh transaksi lain, lock tersebut akan diberikan Jika item sedang dikunci, DBMS menentukan apakah permintaan ini compatible dengan lock saat ini. Jika diminta shared lock pada sebuah item yang sudah mempunyai shared lock terpasang padanya, permintaan lock tersebut akan diijinkan. Selain itu, transaksi harus menunggu sampai lock yang ada terlepas. Sebuah transaksi akan terus memegang lock sampai transaksi tersebut melepasnya baik pada waktu eksekusi ataupun pada waktu transaksi tersebut berakhir (abort atau commit). Efek operasi tulis akan terlihat pada transaksi lain hanya pada waktu exclusive lock telah dilepas. Two-phase Locking (2PL) merupakan sebuah protokol yang memperhatikan saat operasi melakukan lock dan unlock di dalam setiap transaksi. Sebuah transaksi mengikuti protokol two-phase locking jika semua operasi locking mendahului operasi unlock pertama pada transaksi (Connolly, 2005, p589). Sesuai peraturan pada protokol ini, setiap transaksi dapat dibagi ke dalam dua fase, yaitu growing phase dan shrinking phase. Pada growing

22 31 phase, transaksi akan mendapatkan semua lock yang dibutuhkan tapi tidak dapat melepaskan lock apapun. Pada shrinking phase, transaksi akan melepaskan semua lock yang dipegang tapi tidak bisa mendapatkan lock baru lainnya. Tidak ada kebutuhan bahwa semua lock didapatkan sekaligus pada suatu waktu. Secara normal, sebuah transaksi akan mendapatkan lock untuk menjalankan operasi, dan meminta lock tambahan jika ada operasi yang membutuhkan lock pada operasi selanjutnya. Aturan-aturannya adalah sebagai berikut : Sebuah transaksi harus mendapatkan sebuah lock pada item sebelum beroperasi pada item tersebut. Lock tersebut bisa berupa akses membaca atau menulis, tergantung dari tipe akses yang dibutuhkan. Ketika transaksi melepaskan sebuah lock, transaksi tersebut tidak akan pernah mendapatkan lock baru lainnya. Berikut akan dibahas bagaimana two-phase locking digunakan untuk memecahkan tiga masalah concurrency yang telah dibahas sebelumnya Mencegah Masalah Lost Update Menggunakan 2PL Time T 1 T 2 bal x t 1 begin_transaction 100 t 2 begin_transaction write_lock(bal x ) 100 t 3 write_lock(bal x ) read(bal x ) 100

23 32 t 4 WAIT bal x = bal x t 5 WAIT write(bal x ) 200 t 6 WAIT commit / unlock(bal x ) 200 t 7 read(bal x ) 200 t 8 bal x = bal x t 9 write(bal x ) 190 t 10 commit / unlock(bal x ) 190 Tabel 2. 8 Mencegah masalah lost update menggunakan 2PL Sumber : Connoly, 2005, p590 Penjelasan : Solusi pada masalah lost update ditunjukkan pada tabel 2.8. Untuk mencegah masalah lost update terjadi, pertama kali T 2 meminta dan mendapatkan sebuah exclusive lock pada bal x. Dengan demikian T 2 dapat membaca nilai dari bal x, menambah nilainya dengan 100, dan menuliskan nilai tersebut ke dalam database. Ketika T 1 mulai dijalankan, T 1 juga akan meminta sebuah exclusive lock pada bal x. Karena exclusive lock untuk bal x sedang digunakan oleh T 2, maka permintaan ini tidak langsung disetujui. T 1 harus menunggu sampai lock pada bal x yang digunakan oleh T 2 dilepaskan yang artinya T 1 harus menunggu sampai T 2 menyelesaikan semua operasinya.

24 Mencegah Masalah Uncommitted Dependency Menggunakan 2PL Time T 3 T 4 bal x t 1 begin_transaction 100 t 2 write_lock(bal x ) 100 t 3 read(bal x ) 100 t 4 begin_transaction bal x = bal x t 5 write_lock(bal x ) write(bal x ) 200 t 6 WAIT rollback / unlock(bal x ) 100 t 7 read(bal x ) 100 t 8 bal x = bal x t 9 write(bal x ) 90 t 10 commit / unlock(bal x ) 90 Tabel 2. 9 Mencegah masalah uncommitted dependency menggunakan 2PL Sumber : Connoly, 2005,p590 Penjelasan : Solusi pada masalah uncomitted dependency ditunjukkan pada tabel 2.9. Untuk mencegah masalah uncommitted dependency terjadi, pertama kali T 4 meminta dan mendapatkan sebuah exclusive lock pada bal x. Dengan demikian T 4 dapat membaca nilai dari bal x, menambah nilainya dengan 100, dan menuliskan nilai tersebut ke dalam database. Ketika rollback terjadi, semua perubahan pada transaksi T 4 akan mengalami undone sehingga nilai dari bal x akan kembali seperti nilai awalnya yaitu 100. Ketika T 3 mulai

25 34 dijalankan, T 3 juga akan meminta sebuah exclusive lock pada bal x. Karena exclusive lock untuk bal x sedang digunakan oleh T 4, maka permintaan ini tidak langsung disetujui. T 3 harus menunggu sampai lock pada bal x yang digunakan oleh T 4 dilepaskan dan permintaan akan disetujui setelah proses rollback pada transaksi T 4 selesai dikerjakan Mencegah Masalah Inconsistent Analysis Menggunakan 2PL Time T 5 T 6 bal x bal y bal z sum t 1 begin_tran t 2 begin_tran sum= t 3 write_lock(bal x ) t 4 read(bal x ) read_lock(bal x ) t 5 bal x = bal x 10 WAIT t 6 write(bal x ) WAIT t 7 write_lock(bal z ) WAIT t 8 read(bal z ) WAIT t 9 bal z =bal z + 10 WAIT t 10 write(bal z ) WAIT t 11 commit / WAIT unlock(bal x, bal z ) t 12 read(bal x ) t 13 sum=sum+bal x

26 35 t 14 read_lock(bal y ) t 15 read(bal y ) t 16 sum=sum+bal y t 17 read_lock(bal z ) t 18 read(bal z ) t 19 sum=sum+bal z t 20 commit / unlock(bal x, bal y, bal z ) Tabel Mencegah masalah inconsistent analysis menggunakan 2PL Sumber : Connoly,2005, p591 Penjelasan : Untuk mencegah masalah inconsistent analysis terjadi, pertama kali T 5 meminta dan mendapatkan sebuah exclusive lock pada bal x. Dengan demikian T 5 dapat membaca nilai dari bal x, mengurangi nilainya dengan 10, dan menuliskan nilai tersebut ke dalam database. Ketika T 6 mulai dijalankan, T 6 akan meminta sebuah shared lock pada bal x. Karena exclusive lock untuk bal x sedang digunakan oleh T 5, maka permintaan ini tidak langsung disetujui. T 6 harus menunggu sampai exclusive lock pada bal x yang digunakan oleh T 5 dilepaskan dan permintaan akan disetujui setelah semua operasi pada transaksi T 5 selesai dikerjakan.

27 Deadlock Deadlock adalah jalan buntu yang dapat terjadi ketika dua atau lebih transaksi masing-masing menunggu lock yang sedang dipegang oleh transaksi lainnya untuk dilepas (Connolly, 2005, p594). Time T 17 T 18 t 1 begin_transaction t 2 write_lock (bal x ) begin_transaction t 3 read (bal x ) write_lock (bal y ) t 4 bal x = bal x - 10 read (bal y ) t 5 write (bal x ) bal y = bal y t 6 write_lock (bal y ) write (bal y ) t 7 WAIT write_lock (bal x ) t 8 WAIT WAIT t 9 WAIT WAIT t WAIT t Tabel Contoh deadlock pada dua transaksi Sumber : Connoly, 2005, p594 Tabel 2.11 menunjukkan dua transaksi T 17 dan T 18 yang mengalami deadlock karena masing-masing sedang menunggu transaksi lainnya untuk melepaskan lock yang sedang dipegang. Pada saat t 2, transaksi T 17 meminta dan mendapatkan exclusive lock pada item bal x dan pada saat t 3 transaksi T 18 mendapatkan exclusive lock pada item bal y. Pada saat t 6, T 17 meminta

28 37 exclusive lock pada item bal y. Karena T 18 sedang mengunci bal y, maka transaksi T 17 akan menunggu. Sementara itu, pada saat t 7, T 18 meminta sebuah exclusive lock pada item bal x yang sedang dipegang oleh transaksi T 17. Tidak ada satupun transaksi yang dapat dilanjutkan karena masingmasing sedang menunggu lock yang tidak dapat dipenuhi sampai transaksi lainnya selesai. DBMS harus dapat mengetahui adanya deadlock dan mengatasinya dalam beberapa cara. Hanya ada satu cara untuk menghancurkan deadlock, yaitu abort satu atau lebih transaksi. Dengan melakukan abort sebuah transaksi, proses harus melakukan undo terhadap semua perubahan yang dilakukan oleh transaksi tersebut. Pada contoh yang ditunjukkan dalam tabel 2.11, proses abort dapat dilakukan pada transaksi T 18. Setelah abort transaksi T 18 selesai, semua lock yang dipegang oleh transaksi T 18 akan dilepaskan dan dapat digunakan oleh transaksi T 17. Langkah berikutnya, DBMS akan secara otomatis melakukan restart terhadap transaksi yang telah dibatalkan tersebut. Ada tiga teknik umum yang biasa digunakan untuk menangani deadlock, yaitu timeout, deadlock prevention dan deadlock detection and recovery. Dengan timeout, transaksi yang meminta lock akan menunggu selama satu periode waktu tertentu. Dengan menggunakan deadlock prevention, DBMS akan melihat apakah suatu transaksi akan menyebabkan deadlock, dan tidak akan mengizinkan deadlock terjadi. Dengan menggunakan deadlock detection and recovery, DBMS mengizinkan deadlock terjadi namun mengetahui kejadian deadlock, lalu memecahkan

29 38 deadlock tersebut. Karena mencegah deadlock lebih susah daripada menggunakan timeout atau mendeteksi deadlock lalu memecahkannya ketika deadlock terjadi, sistem umumnya menghindari metode deadlock prevention Deadlock Prevention Salah satu pendekatan untuk mencegah deadlock adalah dengan mengurutkan transaksi menggunakan transaction timestamps.. Dua algoritma telah ditemukan oleh Rosenkrantz (1978). Algoritma pertama, Wait-Die, mengijinkan hanya transaksi yang lebih tua untuk menunggu yang lebih muda, jika tidak transaksi dibatalkan dan restart dengan timestamp yang sama, sehingga lama kelamaan transaksi tersebut akan menjadi transaksi aktif tertua dan tidak akan mati. Algoritma kedua, Wound-Wait, menggunakan pendekatan simetrikal. Hanya transaksi yang lebih muda yang dapat menunggu transaksi yang lebih tua. Jika transaksi yang lebih tua meminta lock yang dipegang oleh transaksi yang lebih muda, transaksi yang lebih muda digagalkan. Sebuah variasi dari 2PL, yang disebut sebagai conservative 2PL, dapat juga digunakan untuk mencegah deadlock. Dengan menggunakan conservative 2PL, sebuah transaksi mendapatkan semua lock yang dibutuhkan ketika transaksi dimulai atau transaksi akan menunggu sampai semua kunci yang dibutuhkan telah tersedia. Protokol ini memiliki keuntungan yaitu waktu pengaksesan kunci menjadi berkurang karena

30 39 transaksi tidak pernah ditahan dan bahkan tidak pernah menunggu untuk mendapatkan lock ketika transaksi sedang dieksekusi. Semua lock harus didapatkan dan dilepaskan pada satu waktu tertentu. Sehingga, jika sebuah transaksi gagal mendapatkan sebuah lock, maka transaksi itu harus melepaskan semua lock yang didapatkannya dan memulai lock process dari awal lagi. Dalam pandangan nyata, sebuah transaksi mungkin saja tidak mengetahui lock apa saja yang akan dibutuhkan pada awal transaksi. Protokol ini tidak digunakan dalam realitas pada DBMS Deadlock Detection and Recovery Deadlock detection biasanya ditangani oleh konstruksi wait-for graph (WFG) yang menunjukkan ketergantungan transaksi, yaitu transaksi T i tergantung pada T j jika transaksi T j memegang lock pada sebuah item data yang ditunggu oleh T i. WFG adalah sebuah directed graph G = (N, E ) yang terdiri atas sekumpulan node N dan sekumpulan directed edge E, yang dikonstruksi sebagai berikut : Buat sebuah node untuk setiap transaksi. Buat sebuah directed edge T i T j, jika transaksi T i menunggu untuk melakukan lock pada sebuah item yang sedang di-lock oleh T j. y T 1 T 2 x

31 40 Gambar 2. 2 WFG dengan sebuah Cycle menunjukkan Deadlock antara 2 transaksi Sumber : Connoly, 2005, p596 Deadlock terjadi jika dan hanya jika WFG mengandung sebuah cycle. Gambar di atas menunjukkan WFG yang menunjukkan deadlock antara dua transaksi. Algoritma dari deadlock detection akan membuat WFG pada selang waktu tertentu dan mengecek apakah terdapat cycle pada WFG tersebut. Jika terjadi deadlock, DBMS harus melakukan abort terhadap salah satu transaksi. Ada beberapa hal yang perlu diperhatikan dalam hal ini, yaitu : Choice of deadlock victim Logika pemilihan transaksi mana yang mengalami proses abort mungkin saja membingungkan. Dalam hal ini dapat dipertimbangkan beberapa hal berikut, yaitu, berapa lama transaksi telah berjalan. Akan lebih baik jika proses abort dilakukan pada transaksi yang baru saja dimulai daripada transaksi yang telah berjalan lebih lama didalam sistem. Pertimbangan berikutnya yaitu berapa banyak data item yang telah diubah oleh transaksi. Akan lebih baik jika proses abort dilakukan pada transaksi yang sedikit melakukan perubahan di dalam database. Pertimbangan berikutnya yaitu, berapa banyak data item yang masih harus diubah. Akan

32 41 lebih baik jika proses abort dilakukan pada transaksi yang memiliki lebih banyak data item untuk diubah didalam database. How far to roll a transaction back Dengan memutuskan terjadinya proses abort pada sebuah transaksi, maka DBMS akan melakukan rollback terhadap transaksi tersebut. Salah satu cara untuk mengatasi deadlock dapat dilakukan dengan melakukan rollback sebagian transaksi yang telah berjalan. Avoiding starvation Starvation terjadi ketika transaksi yang sama selalu terpilih sebagai victim, dan transaksi tidak pernah berjalan sampai selesai. DBMS dapat menghindari starvation dengan menyimpan jumlah berapa kali sebuah transaksi pernah terpilih sebagai victim dan menggunakan kriteria pemilihan yang berbeda jika jumlah tersebut telah mencapai angka tertentu Timeout Pendekatan sederhana pada pencegahan deadlock adalah berdasarkan lock timeout. Dengan pendekatan ini, sebuah transaksi yang meminta sebuah lock akan menunggu hanya sampai periode waktu tertentu yang didefinisikan sistem. Jika kunci yang diminta tidak didapatkan selama periode tersebut, maka terjadi request time out pada transaksi tersebut. Dalam hal ini, DBMS mengasumsikan telah terjadi deadlock, walaupun mungkin saja deadlock tidak terjadi. Dengan demikian, transaksi tersebut

33 42 akan mengalami proses abort dan secara otomatis transaksi tersebut akan mengalami proses restart. Protokol ini merupakan solusi yang umum digunakan untuk mengatasi deadlock didalam sebuah DBMS. Pada penulisan skripsi ini, penulis menggunakan mekanisme timeout untuk mengatasi kemungkinan terjadinya deadlock. Pada aplikasi server, terdapat menu untuk memilih waktu yang akan digunakan sebagai selang waktu terjadinya timeout. Jika sebuah transaksi telah berjalan dan menunggu sebuah lock, maka timer yang menandakan awal waktu menunggu akan dimulai. Jika transaksi masih menunggu lock sampai selang waktu tersebut habis, maka terjadi timeout. Transaksi tersebut akan mengalami proses rollback dan restart dari awal dengan lama waktu menunggu lock yang dibutuhkan diubah kembali menjadi nol. 2.5 Alat Bantu Perancangan Sistem Alat bantu perancangan sistem menggunakan UML. UML adalah sebuah bahasa yang telah menjadi standar dalam industri untuk memvisualisasi, menspesifikasi, merancang dan mendokumentasi sistem piranti lunak (Booch et al, 1999, p14). UML menawarkan sebuah standar untuk merancang model sebuah sistem Use Case Diagram Use Case Diagram menggambarkan sekumpulan use case dan aktor serta hubungannya (Booch et al, 1999, p234). Yang ditekankan adalah apa yang dilakukan terhadap sistem dan bukan bagaimana. Sebuah use

34 43 case menggambarkan interaksi antara aktor dengan sistem. Di bawah ini dijelaskan bagian use case diagram: a. Aktor Aktor adalah segala sesuatu yang melakukan tatap muka dengan sistem, seperti orang, piranti lunak, piranti keras, atau jaringan (Schneider dan Winters, 1997, p12). Tiap-tiap aktor menunjukkan perannya masing-masing. Notasi aktor dengan nama aktor tersebut dibawahnya: Pengguna b. Use case Use case menggambarkan segala sesuatu yang aktor ingin lakukan terhadap sistem. Use case harus merupakan apa yang yang dikerjakan piranti, bukan bagaimana aplikasi piranti lunak mengerjakannya. Suatu sistem yang kompleks memiliki banyak use case, sehingga perlu diorganisasi. Notasi use case: Untuk menghubungkan antara aktor dengan use case digunakan simbol garis yang disebut sebagai relationship.

35 44 Suatu use case dapat memiliki deskripsi teknik, yaitu: extends, dan include. <<extends>> Extends berarti memperluas use case dasar dengan menambah behavior-behavior baru tanpa mengubah use case dasar itu sendiri. Titik di mana use case diperluas disebut sebagai extension point. <<include>> Sebuah use case dapat meng-include fungsionalitas dari use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Dengan adanya use case diagram maka akan membantu dalam menyusun kebutuhan sebuah sistem dan mengkomunikasikannya dengan client Class Diagram Class Diagram menunjukkan entitas yang ada pada sistem dan bagaimana entitas tersebut saling berhubungan (Booch et al, 1999, p107). Entitas tersebut memiliki atribut dan perilaku tertentu. Class diagram memperlihatkan hubungan antarkelas dan penjelasan detail tiap-tiap kelas di dalam logical view dari suatu sistem. Class tersusun dari tiga bagian,

36 45 yaitu nama class, attribute, dan method operasi. Berikut ini adalah contoh sebuah class : Gambar 2. 3 Struktur Class Sumber : Whitten, 2004, p Diagram Alir (Flow Chart) Diagram alir adalah suatu representasi grafis di mana simbol-simbol digunakan untuk merepresentasikan operasi, data, aliran, logika, perlengkapan, dan seterusnya. Suatu diagram alir program mengilustrasikan struktur dan urutan dari operasi sebuah program, sementara sebuah sistem diagram alir mengilustrasikan komponenkomponen dan aliran sistem informasi (O Brien, 2003, pg-8). Tiga konsep utama dalam pemrograman terstruktur yaitu sequence, condition, dan repetition (Pressman, 2001, p424). Sequence mengimplementasikan langkah-langkah proses yang penting dalam spesifikasi algoritma-algoritma. Condition menyediakan fasilitas untuk memilih proses berdasarkan logika, dan repetition untuk melakukan proses perulangan.

37 46 Condition First task F T Next task Else-part Then-part Sequence If-then-else Case condition T F Case part T F T F T T F F Selection Do-while Repetition Repeat-until Gambar 2. 4 Flowchart Constructs Sumber : Pressman, 2001, p XML XML adalah sebuah meta-language (bahasa yang digunakan untuk mendeskripsikan bahasa lain) yang memungkinkan seorang designer membuat sendiri tag yang menyediakan fungsi yang tidak tersedia dalam HTML (Connolly, 2005, p1073). XML merupakan sebuah versi meta-language yang diturunkan dari Standard Generalized Markup Language (SGML), yang di desain khusus untuk dokumen website dan dapat mendukung perancang untuk menciptakan tag sendiri, yang memiliki kemampuan untuk mendefinisikan, mentransmisikan, memvalidasikan dan menginterpretasikan data antara aplikasi dan organisasi. XML dikembangkan oleh World Wide Web Consortium (W3C) yang didukung sekitar 150 orang anggotanya dan versi 1.0 pertama kali dirilis pada tahun 1998.

38 47 Keunggulan yang dimiliki XML antara lain (Connolly, 2005, p1074) : Simplicity. XML menggunakan bahasa yang sederhana, mudah dimengerti oleh manusia dan mesin. Open standar and platform / vendor-independent. XML menggunakan standar terbuka dan tidak tergantung pada platform tertentu. Extensibility. XML memungkinkan user untuk mendefinisikan tag sendiri sehingga dapat dikembangkan sesuai dengan kebutuhan user. Reuse. XML memungkinkan libraries dari XML tags untuk dibangun sekali dan dapat digunakan kembali oleh banyak aplikasi. Separation of content and presentation. XML memisahkan antara isi dan tampilan dari suatu data sesuai dengan pengaturan yang diinginkan. Improved load balancing. Data dapat ditampilkan pada browser dengan baik. Support for the integration of data from multiply source. Kemampuan mengintegrasikan data dari berbagai macam sumber yang berbeda adalah hal yang sulit dan memakan waktu. XML dapat menggabungkan data dari banyak sumber yang berbeda dengan cara yang mudah. Ability to describe data from a wide variety of applications. XML dapat digunakan untuk mendeskripsikan data yang terdapat pada aplikasi yang berbeda. More advance search engine. Dengan XML, mesin pencarian akan mampu untuk menyederhanakan berbagai macam tags.

39 48 New opportunities. XML memiliki banyak kelebihan yang dapat dihadirkan dalam banyak aplikasi teknologi saat ini. Struktur hirarkisnya cocok untuk kebanyakan tipe dokumen. Kekurangan-kekurangan XML : Parser harus didesain untuk memahami struktur data bersarang yang berubah-ubah dan harus melakukan pengecekan tambahan untuk mendeteksi sintaks atau data yang tidak terformat atau terurut dengan benar. Urutan penekanan tombol untuk mengetikkan ekspresi XML pada keyboard standar komputer seringkali kaku. XML menggunakan teknologi Document Type Definitions (DTDs) yang dapat mendefinisikan sintaks yang valid dari dokumen XML. Contoh bahasa XML : <?xml version= 1.0 encoding= UTP-8 standalone= yes?> <?xml:stylesheet type= text/xsl href= staff_list.xsl?> <!DOCTYPE STAFFLIST SYSTEM staff_list.dtd > <STAFFLIST> <STAFF branchno= B005 > <STAFFNO>SL21</ STAFFNO> <NAME>

40 49 <FNAME>John</FNAME> <LNAME>White</LNAME> </NAME> <POSITION>Manager</POSITION> <DOB> </DOB> <SALARY>30000</SALARY> </STAFF> <STAFF branchno= B003 > <STAFFNO>SL37</ STAFFNO> <NAME> <FNAME>Ann</FNAME> <LNAME>Beech</LNAME> </NAME> <POSITION>Assistant</POSITION> <SALARY>12000</SALARY> </STAFF> </STAFFLIST> Deklarasi XML Sebuah file XML diawali dengan pilihan deklarasi XML, yang menunjukkan versi XML yang digunakan oleh penulis dalam dokumen, encoding system yang digunakan dan menentukan apakah ada deklarasi external markup yang perlu dimasukkan. XML bersifat case-sensitive

41 50 (huruf kecil tidak sama dengan huruf besar). Artinya tag <price> dan <Price> merupakan hal yang berbeda Elemen XML Elemen, atau tag, adalah bentuk umum dalam markup. Elemen pertama pasti adalah sebuah root element, yang dapat terdiri atas banyak sub elemen lain. Sebuah dokumen XML harus mempunyai satu root element. Root element contoh diatas adalah <STAFFLIST>. Setiap elemen diawali dengan tag awal (<STAFF>) dan diakhiri dengan tag akhir (</STAFF>). Sebuah elemen yang kosong ditunjukan dengan tag : <EMPTYELEMENT/>. Tag harus disarangkan dengan benar. Maksudnya adalah satu tag bisa berada di dalam tag lain (disarangkan), namun tag pembuka dan tag penutupnya harus berada di antara tag pembuka dan penutup dari tag yang mengelilinginya. Contoh Tag bersarang: <STAFF> <NAME> <FNAME>Ann</FNAME> <LNAME>Beech</LNAME> </NAME> </STAFF> Pada contoh tersebut, elemen NAME bersarang di dalam elemen STAFF, elemen FNAME dan LNAME bersarang di dalam elemen NAME.

42 Atribut XML Atribut adalah pasangan nama dan nilai yang mendeskripsikan informasi tentang suatu elemen. Atribut diletakkan dalam tag awal setelah nama elemen dan nilai atribut ada dalam tanda petik. Contoh : <STAFF brachno= B005 >. Jika sudah diberikan atribut maka dapat ditunjukkan elemen itu adalah elemen yang kosong, contoh : <SEX gender= M /> Entity References Setiap entiti harus memiliki nama yang unik dan penggunaannya dalam sebuah dokumen XML disebut dengan entity reference. Sebuah entity reference diawali dengan tanda dan (&) dan diakhiri dengan titik koma (;). Entity reference adalah karakter yang mengganti illegal character di XML ( Terdapat lima predefined entity references pada XML, yaitu : < < less than > > greater than & & ampersand &apos; ' Apostrophe " " quotation mark Tabel Predefined entity references pada XML Sumber :

43 Komentar XML Komentar pada XML menggunakan sintaks sama seperti komentar pada HTML. Contoh: <!-- ini adalah komentar -- > Komentar ini dapat mengandung semua string kecuali CDATA Section dan Instruksi Proses CDATA section memberitahu prosesor XML untuk melewati karakter markup dan memberikan teks langsung ke aplikasi tanpa melakukan interpretasi. Instruksi proses dapat digunakan untuk menyediakan informasi ke sebuah aplikasi. Jika mengandung banyak karakter < atau &, elemen XML bisa didefinisikan sebagai CDATA. Contoh ( <script> <![CDATA[ function matchwo(a,b) { if (a < b && a < 0) then { return 1 } else { return 0 } } ]]> </script> Urutan Dalam XML urutan elemen sangatlah penting. Jadi, jika urutan elemen berbeda maka akan dianggap sebagai data yang berbeda. Contoh : <NAME> <FNAME>John</FNAME>

44 53 <LNAME>White</LNAME> </NAME> akan berbeda dengan <NAME> <LNAME>White</LNAME> <FNAME>John</FNAME> </NAME> Dalam XML urutan atribut tidak terpengaruh. Contoh : <NAME FNAME= John LNAME= White /> <NAME LNAME= White FNAME= John /> Dua elemen diatas akan dianggap sama oleh prosesor XML. 2.7 Parser Setiap bahasa program mempunyai aturan-aturan yang memberikan struktur sintaks dari program-program yang terbentuk baik. Sintaks suatu bahasa program dapat digambarkan oleh notasi tata bahasa bebas konteks (Context-Free Grammar). Tata bahasa bebas konteks adalah sebuah string yang dibentuk dari himpunan simbol-simbol. Tata bahasa itu sendiri memberikan keuntungan besar baik kepada perancang bahasa ataupun penulis kompilator. Keuntungan itu antara lain :

45 54 1. Terhadap bahasa program itu sendiri, tata bahasa memberikan penjelasan sintaks yang jelas dan mudah dimengerti. 2. Dari tata bahasa kelas tertentu, secara otomatis dapat dibentuk parser yang efisien dan yang dapat menentukan apakah suatu program sumber menuliskan sintaks dengan benar atau tidak. 3. Dari tata bahasa yang dirancang dengan baik, terbentuk suatu struktur pada bahasa program yang berguna untuk pengubahan bahasa sumber menjadi kode objek yang benar dan berguna untuk pendeteksian kesalahan. 4. Bahasa program berkembang dalam suatu periode waktu dengan menampilkan construct baru dan menyajikan kemampuan tambahan. Construct-construct ini dapat ditambahkan secara mudah ke dalam suatu bahasa jika sudah ada implementasi yang berdasarkan deskripsi tata bahasa dari bahasa itu (Aho, 1986, p157). Parsing adalah proses menganalisa urutan token dengan tujuan untuk menentukan struktur tata bahasanya dibandingkan dengan tata bahasa normal yang diberikan ( Proses ini secara formal disebut analisis sintaks. Parser adalah sebuah program komputer yang menjalankan tugas ini. Parser adalah sebuah program, biasanya bagian dari sebuah compiler, yang menerima input dalam bentuk instruksi program sumber secara sekuensial, perintah-perintah online yang interaktif, tag-tag markup, atau beberapa interface terdefinisi lainnya, dan memecahkannya menjadi bagian-bagian ( Sebuah parser bisa juga mengecek apakah semua input yang diperlukan sudah disediakan dengan lengkap dan sesuai.

46 Queue Pada penulisan ini, queue akan digunakan untuk mengimplementasikan schedule transaksi dan operasi didalamnya. Pada aplikasi ini, sebuah transaksi dapat terdiri atas satu atau banyak operasi. Semua operasi didalam satu transaksi akan disimpan ke dalam queue. Setiap operasi akan diproses sesuai prinsip queue. Sebuah queue adalah sebuah daftar terurut di mana semua penambahan data dilakukan pada ujung yang satu dan semua penghapusan data dilakukan pada ujung sebaliknya (Horowitz, 2003, p104). Diberikan sebuah queue Q = (a 0, a 1,, a n-1 ), a 0 adalah elemen depan, a n-1 adalah elemen belakang, dan a i+1 berada di belakang a i, 0 i n-1. Batasan pada sebuah queue berlaku jika kita menambahkan data A, B, C, D, dengan urutan itu, maka A adalah elemen pertama yang dihapus dari queue. Gambar 2.6 menggambarkan alur kejadian ini. Karena elemen pertama yang ditambahkan ke dalam queue adalah elemen pertama yang dihapus, queue juga dikenal sebagai daftar First-In-First-Out (FIFO). D rear C rear C D rear B rear B B C A rear front A front A front A front B front Gambar 2.6 Menambahkan dan menghapus elemen dalam sebuah queue (rear = belakang, front = depan)