IMPLEMENTASI REPLIKASI DI MYSQL 5.1 PADA SISTEM
INFORMASI ASURANSI PERSONAL ACCIDENT
(
Studi Kasus PT. Asuransi Umum Sarana Lindung Upaya)
SKRIPSI
Ditujukan Untuk Memenuhi Salah Satu Syarat
Memperoleh Gelar Sarjana Teknik
Jurusan Teknik Informatika
Oleh :
Astrisia Ratih Kusuma
035314021
JURUSAN TEKNIK INFORMATIKA
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SANATA DHARMA
YOGYAKARTA
(A
Study At Case PT. Asuransi Umum Sarana Lindung Upaya)
A Thesis
Presented as Partial Fulfillment of the Requirements
To Obtain the Engineering Bachelor Degree
In Informatics Engineering
By :
Astrisia Ratih Kusuma
035314021
DEPARTMENT OF INFORMATICS ENGINEERING
FACULTY OF SCIENCE AND TECHNOLOGY
SANATA DHARMA UNIVERSITY
YOGYAKARTA
2008
PERNYATAAN KEASLIAN KARYA
Saya menyatakan dengan sesungguhnya bahwa tugas akhir yang saya tulis tidak
memuat karya atau bagian karya orang lain, kecuali yang telah disebutkan dalam
kutipan dan daftar pustaka, sebagaimana layaknya karya ilmiah.
Yogyakarta, 17 Maret 2007
Penulis
Astrisia Ratih Kusuma
HALAMAN MOTTO
DO THE RI GHT
AND DO THE BEST
THEN GOD W I LL DO THE REST
Untuk Mama dan Babe tercinta
Untuk Ema, Tatha, dan Wiwinku tersayang
INTISARI
Seiring dengan berkembangnya suatu perusahaan, beberapa kantor cabang mulai dibangun di beberapa daerah. Hal tersebut menyebabkan dibutuhkan waktu yang lama untuk memenuhi ketersediaan data kantor pusat, karena kantor cabang masih harus mengirimkan data-data tersebut melalui jasa pos.
Tugas akhir ini mengembangkan sistem database terdistribusi, yang dibatasi pada replikasi untuk meningkatkan ketersediaan data dan partisi untuk meningkatkan pengelolaan data. Replikasi akan diimplementasikan pada database
kantor cabang, yaitu jakarta, dengan menggunakan jenis replikasi master-slave.
Sedangkan partisi akan diimplementasikan pada tabel klaim dan tabel polis,
dengan partition by range sebagai jenis partisinya. Dan dengan menggunakan
kasus yang ada pada asuransi, khususnya asuransi personal accident.
Hasil akhir yang diperoleh adalah efisiensi dalam mengelola data yang ada dan dalam menyediakan data dari kantor cabang ke kantor pusat. Sistem ini dibuat dengan menggunakan bahasa pemrograman Java dan MySQL 5.1.19 sebagai
database.
main office, because the branch office still sending the data through the mail. This final project is developing the distributed database system that limited on replication to obtain the distribution data and partitioning to obtain the management data. Replication will implement on branch office’s database, which is Jakarta, using master-slave replication. Partitioning will implement on table klaim and polis, using partition by range. The implementation is using a case in insurance, especially personal accident insurance.
The result of this implementation is the efficiency in maintaining and distributing data from branch office to main office. This system is created by using Java as programming language and MySQL 5.1.19 as database.
KATA PENGANTAR
Puji dan syukur saya haturkan kepada Tuhan Yesus Kristus, karena atas ijin
dan kehendak-Nya saya dapat menyelesaikan tugas akhir ini.
Dalam proses penulisan tugas akhir ini saya menyadari bahwa ada begitu
banyak pihak yang telah memberikan perhatian dan bantuan dengan caranya
masing-masing sehingga tugas akhir ini dapat selesai. Oleh karena itu saya ingin
mengucapkan terima kasih antara lain kepada :
1. Bapak Ir. Gregorius Heliarko, S.J., S.S., B.S.T., M.A., M.Sc. selaku Dekan
Fakultas Sains dan Teknologi, Universitas Sanata Dharma.
2. Ibu Ridowati Gunawan, S.Kom., M.T., selaku Dosen Pembimbing Tugas
Akhir dan Dosen Pembimbing Akademik, yang telah banyak memberikan
bimbingan, dukungan, motivasi dan fasilitas yang mendukung
terselesaikannya tugas akhir ini.
3. Ibu Agnes Maria Polina, S.Kom., M.Sc., selaku Ketua Jurusan Teknik
Informatika.
4. Bapak St. Wisnu Wijaya, S.T., M.T dan Bapak Alb. Agung Hadhiatma,
S.T., M.T. selaku panitia penguji yang telah memberikan banyak kritik dan
saran untuk tugas akhir saya.
5. Seluruh staff dosen Teknik Informatika Universitas Sanata Dharma yang
telah banyak memberikan bekal ilmu, arahan dan pengalaman selama saya
menempuh studi.
Jakarta, yang telah memberikan bantuan dalam menyelesaikan tugas akhir.
8. Mama dan Babe tercinta. Terima kasih atas semua yang telah dilakukan
untukku, doa, semangat, dukungan, perhatian dan cintanya sehingga saya
bisa menyelesaikan studi dengan lancar.
9. My beloved sisters, Tatha dan Ema. Terima kasih atas dukungan, doa,
semangat dan keceriaan yang telah diberikan.
10. Andreas Agus Winarno, terima kasih atas segala cinta, sayang, perhatian,
kesetiaan, kesabaran, ilmu, waktu dan semua yang telah kamu berikan
padaku.
11. Teman-teman Informatika : Sarah dan Merry atas kerja sama dalam
pengerjaan kerja praktek dan seminar kita. Agus, Fenddy, Sarah, Devi atas
kerja sama dalam proyek RPL. Adwi, Angga, Ellen, Ones, JeJe, Yansen,
Abe, Pakde, Ina, Dea, Hendro, Dian, Winda, Uthe, Jun, Bergas, Eko,
Hendrik, Dion, Danang, Heni, Marcel, Isti, Kristin, Ratih, Irvan, Gina, Anis,
Epot, Dani, Wikan, Linda, Rissa, Santos, Amin, Ari, Seno, Chandra, Hana,
Davied, Tika, Marry, Monic, Yeyen, Erick, Pamako, Nur, Rubin, Essther,
Oscar, Ria, Rachel; dan semua teman-teman TI lainnya.
12. Seluruh pihak yang telah ambil bagian dalam proses penulisan tugas akhir
ini yang tidak bisa saya sebutkan satu per satu.
Dengan rendah hati saya menyadari bahwa tugas akhir ini masih jauh dari
sempurna, oleh karena itu berbagai kritik dan saran untuk perbaikan tugas akhir
ini sangat saya harapkan. Akhir kata, semoga tugas akhir ini bermanfaat bagi
semua pihak. Terima kasih.
Yogyakarta, 17 Maret 2008
Penulis
HALAMAN PERSETUJUAN ...
HALAMAN PENGESAHAN ...
PERNYATAAN KEASLIAN KARYA ...
LEMBAR PERNYATAAN PERSETUJUAN PUBLIKASI...
HALAMAN MOTTO ...
HALAMAN PERSEMBAHAN ...
INTISARI...
ABSTRACT ...
KATA PENGANTAR ...
DAFTAR ISI ...
DAFTAR GAMBAR ...
DAFTAR TABEL ...
1.1 Latar Belakang Masalah ...
1.2 Rumusan Masalah ...
1.3 Batasan Masalah ...
1.4 Tujuan dan Manfaat Penelitian...
1.5 Metodelogi Penelitian ...
1.6 Sistematika Penulisan ...
BAB II. LANDASAN TEORI
2.1 Database...
2.2 Distributed Database Management System (DDBMS)...
2.3 Sistem Database Terdistribusi
2.3.1 Pengertian Sistem Database Terdistribusi…...
2.3.2 Transparansi pada Sistem Terdistribusi…...
2.3.3 Tujuan Sistem Database Terdistribusi...
2.4 Replikasi di MySQL………
2.5 Partisi di MySQL 5.1
2.5.1 Jenis – Jenis Partisi di MySQL 5.1...
2.5.2 Aturan dan Batasan Partisi di MySQL 5.1...
BAB III. ANALISIS DAN PERANCANGAN SISTEM
3.1 Analisis Sistem
3.1.1Gambaran Umum Sistem Lama...
3.1.2Orang Yang Terlibat Dalam Sistem...
3.1.3Analisis Masalah...
3.1.4Gambaran Umum Sistem Baru...
3.1.5Desain Arsitektur Replikasi...
3.1.6Use Case Diagram
3.1.6.1 Use Case Diagram Admin...
3.1.6.1.1Use Case Diagram Admin Sub Proses Pengaturan
3.1.6.1.3Use Case Diagram Admin Sub Proses Pengajuan
Klaim...
3.1.6.2 Use Case Diagram Karyawan Bagian Teknik...
3.1.6.3 Use Case Diagram Karyawan Bagian Klaim...
3.1.6.4 Use Case Diagram Kepala Bagian
3.1.6.4.1Use Case Diagram Kepala Bagian Teknik……….
3.1.6.4.2Use Case Diagram Kepala Bagian Klaim……...
3.1.6.5 Use Case Diagram Kepala Cabang……...
3.1.6.6 Use Case Diagram Kepala Divisi..……...
3.2 Desain Sistem
3.2.1Sequence Diagram...
3.2.2Class Diagram...
3.2.3Desain Database ...
3.2.3.1 Entity Relationship Diagram...
3.2.3.2 Tabel Karyawan...
3.2.3.3 Tabel Perusahaan...
3.2.3.4 Tabel Bank……...
3.2.3.5 Tabel Polis……...
3.2.3.6 Tabel Klaim…...
3.2.3.7 Tabel Premi…...
3.2.3.8 Tabel Kantor…...
3.2.3.9 Tabel Reasuransi...
3.2.3.10 Tabel Kondisi Polis...
3.2.3.11 Tabel Kondisi Klaim...
3.2.3.12 Tabel Jabatan………...
3.2.3.13 Tabel User...
3.2.4Pemilihan Jenis Partisi...
3.2.5Desain User Interface
3.2.5.1 Desain Input
3.2.5.1.1Form Login...
3.2.5.1.2Form Setting Koneksi...
3.2.5.1.3Form Menu Utama...
3.2.5.1.4Form Agenda Polis...
3.2.5.1.5Form Menambah Agenda Polis...
3.2.5.1.6Form Mengupdate Agenda Polis...
3.2.5.1.7Form Agenda Klaim...
3.2.5.1.8Form Menambah Agenda Klaim...
3.2.5.1.9Form Mengupdate Agenda Klaim...
3.2.5.1.10 Form PLA...
3.2.5.1.11 Form DLA...
3.2.5.1.12 Form Persetujuan Klaim...
3.2.5.1.13 Form Outstanding Klaim...
3.2.5.1.14 Form Setting Bank...
3.2.5.1.18 Form Setting User...
3.2.5.1.19 Form Proses List...
3.2.5.2 Desain Output
3.2.5.2.1Laporan Agenda Klaim...
3.2.5.2.2Laporan Agenda Polis...
BAB IV. IMPLEMENTASI SISTEM
4.1 Implemetasi Replikasi ...
4.1.1Membuat Database Jakarta dan Semarang...
4.1.2Membuat User Slu...
4.1.3Membuat Tabel – Tabel yang Dibutuhkan Untuk Membangun
Sistem
4.1.3.1Tabel Bank...
4.1.3.2Tabel Jabatan...
4.1.3.3Tabel Kantor...
4.1.3.4Tabel Karyawan...
4.1.3.5Tabel Klaim...
4.1.3.6Tabel Kondisi Klaim...
4.1.3.7Tabel Kondisi Polis...
4.1.3.8Tabel Perusahaan...
4.1.3.9Tabel Polis...
4.1.3.10 Tabel Premi...
4.1.3.11 Tabel Reasuransi...
4.1.3.12 Tabel User...
4.1.4Mengatur Konfigurasi Untuk Database Server Master...
4.1.5Mengatur Konfigurasi Untuk Database Server Slave...
4.1.6Menjalankan Replikasi...
4.2 Koneksi Ke Database MySQL...
4.3 Implementasi User Interface
4.3.1Form Login...
4.3.2Form Setting Koneksi...
4.3.3Form Menu Utama...
4.3.4Form Agenda Polis...
4.3.5Form Menambah Agenda Polis...
4.3.6Form Mengupdate Agenda Polis...
4.3.7Form Agenda Klaim...
4.3.8Form Menambah Agenda Klaim...
4.3.9Form Mengupdate Agenda Klaim...
4.3.10 Form PLA...
4.3.11 Form DLA...
4.3.12 Form Persetujuan Klaim...
4.3.13 Form Outstanding Klaim...
4.3.14 Form Setting Bank...
4.3.18 Form Setting User...
4.3.19 Form Proses List...
BAB V. ANALISIS HASIL
5.1 Analisis Teknologi
5.1.1Partisi...
5.1.2Replikasi...
5.2 Kelebihan dan Kekurangan Sistem
5.2.1Kelebihan Sistem ... ...
5.2.2Kekurangan Sistem ...
BAB VI. PENUTUP
6.1 Kesimpulan ...
6.2 Saran ...
DAFTAR PUSTAKA
DAFTAR GAMBAR
Gambar Keterangan Halaman
3.1 Desain Arsitektur Replikasi dan Partisi 20
3.2 Use Case Diagram Admin 22
3.3 Use Case Diagram Admin Sub Proses Pengaturan Data 23
3.4 Use Case Diagram Admin Sub Proses Pembuatan Polis 24
3.5 Use Case Diagram Admin Sub Proses Pengajuan Klaim 25
3.6 Use Case Diagram Karyawan Bagian Teknik 26
3.7 Use Case Diagram Karyawan Bagian Klaim 27
3.8 Use Case Diagram Kepala Bagian Teknik 28
3.9 Use Case Diagram Kepala Bagian Klaim 29
3.10 Use Case Diagram Kepala Cabang 30
3.11 Use Case Diagram Kepala Divisi 31
3.12 Class Diagram 38
3.13 Entity Relationship Diagram 40
3.14 Form Login 48
3.15 Form Setting Koneksi 48
3.16 Form Menu Utama 49
3.17 Form Agenda Polis 49
3.18 Form Menambah Agenda Polis 50
3.19 Form Mengupdate Agenda Polis 50
3.20 Form Agenda Klaim 51
3.21 Form Menambah Agenda Klaim 51
3.22 Form Mengupdate Agenda Klaim 52
3.23 Form PLA 52
3.24 Form DLA 53
3.25 Form Persetujuan Klaim 53
3.26 Form Outstanding Klaim 54
3.31 Form Setting User 56
4.5 Form Menambah Agenda Polis 73
4.6 Form Mengupdate Agenda Polis 74
4.7 Form Agenda Klaim 75
4.8 Form Menambah Agenda Klaim 76
4.9 Form Mengupdate Agenda Klaim 77
4.10 Form PLA 78
5.1 Contoh Hasil Menampilkan Data Agenda Klaim
Menggunakan Database jakarta 88
5.2 Contoh Hasil Menampilkan Data Agenda Klaim
Menggunakan Database jakarta2 89
5.3 Contoh Menampilkan Data Agenda Polis Menggunakan
Replikasi 93
5.4 Contoh Menampilkan Data Agenda Polis Dengan
Mengakses Langsung ke DatabaseMaster 94
3.1 Tabel Karyawan 41
3.9 Tabel Kondisi_polis 45
3.10 Tabel Kondisi_klaim 45
3.11 Tabel Jabatan 46
3.12 Tabel User 46
5.1 Hasil Percobaan Menampilkan Agenda Polis Pada
Database yang Menggunakan Partisi dan yang Tidak
Menggunakan Partisi
90
5.2 Hasil Percobaan Menampilkan Agenda Klaim Pada
Database yang Menggunakan Partisi dan yang Tidak
Menggunakan Partisi
91
5.3 Hasil Percobaan Menampilkan Agenda Polis Pada
Database yang Menggunakan Replikasi dan yang Tidak
Menggunakan Replikasi
95
BAB I
PENDAHULUAN
1.1. Latar Belakang Masalah
Seiring perkembangan teknologi informasi saat ini, banyak bidang usaha
yang membutuhkan teknologi informasi untuk mengatasi masalah-masalah yang
dihadapi. Salah satu masalah yang ada adalah ketika suatu perusahaan mulai
berkembang dan mulai membangun beberapa kantor cabang yang terpisah
secara geografis. Hal tersebut menjadi masalah ketika kantor cabang harus
dapat menyediakan data yang cukup banyak untuk menghasilkan informasi
yang dibutuhkan oleh kantor pusat untuk menjalankan sistem kerjanya.
Meskipun masalah di atas mungkin diselesaikan dengan membangun sebuah
database server pada setiap kantor pusat dan cabang yang terhubung dalam
sebuah jaringan, tetapi hal tersebut akan menyebabkan hilangnya komunikasi
antardatabase saat jaringan tersebut terputus. Sedangkan untuk menangani data
cukup banyak yang dihasilkan oleh setiap kantor, maka digunakan partisi pada
beberapa database yang memiliki data yang cukup banyak. Salah satu cara yang
mungkin dilakukan adalah dengan membangun sistem dengan database
terdistribusi yang mengimplementasikan replikasi dan partisi.
PT.Asuransi Sarana Lindung Upaya sebagai salah satu perusahaan yang
bergerak dalam bidang asuransi yang memiliki beberapa cabang yang terpisah
secara geografis. Setiap kali kantor cabang memproduksi sebuah polis ataupun
klaim, maka data-data tersebut harus dikirimkan melalui pos ke kantor pusat.
Biasanya pengiriman data-data tersebut membutuhkan waktu satu malam untuk
sampai ke kantor pusat. Pada perusahaan ini seluruh data yang ada masih
disimpan dalam bentuk berkas. Hal tersebut akan menyulitkan dalam pencarian
data, karena data – data yang ada cukup banyak. Sehingga diharapkan dengan
dibangun sebuah sistem dengan database terdistribusi yang
mengimplementasikan replikasi dan partisi dapat memudahkan dalam
memproses data yang ada dan mengirimkan data ke kantor pusat.
1.2. Rumusan Masalah
Dari latar belakang masalah yang telah dikemukakan dapat diperoleh
rumusan masalah, yaitu bagaimana mengimplementasikan replikasi dan partisi
di MySQL 5.1 pada sistem informasi asuransi personal accident dengan
3
1.3. Batasan Masalah
Untuk memusatkan penelitian pada pokok masalah, maka pembahasan
masalah pada tulisan ini akan dibatasi pada hal-hal berikut:
1. Hanya menitikberatkan pada replikasi di MySQL 5.1
2. Sistem database terdistibusi dibatasi pada penggunaan teknologi replikasi
single-master.
3. Jenis replikasi yang digunakan adalah replikasi master-slave, dimana
database pada kantor cabang Jakarta sebagai slave dan database pada
kantor pusat Semarang sebagai master.
4. Sistem tidak menangani pembayaran premi.
1.4. Tujuan dan Manfaat Penelitian
Tujuan dari penelitian yang dilakukan adalah menerapkan replikasi dan
partisi di MySQL 5.1 pada sistem informasi asuransi personal accident.
Adapun manfaat dari penilitian yang dilakukan adalah untuk membantu
memudahkan PT. Asuransi Umum Sarana Lindung Upaya dalam memproses
1.5. Metodologi Penelitian
Metodologi penelitian yang digunakan adalah :
1. Studi literatur
Mengumpulkan dan mempelajari data atau informasi melalui buku,
laporan, makalah, dan media informasi lainnya yang sesuai dengan sistem
yang dibuat.
2. Identifikasi masalah
Menggunakan teknik antara lain :
a. Mengambil data-data asuransi personal accident di PT. Asuransi
Umum Sarana Lindung Upaya cabang Jakarta.
b. Pengamatan (observasi) : melakukan pengamatan langsung di PT.
Asuransi Umum Sarana Lindung Upaya cabang Jakarta.
c. Wawancara (interview) : memperoleh keterangan untuk tujuan
penelitian dengan cara tanya jawab secara langsung dengan karyawan
PT. Asuransi Umum Sarana Lindung Upaya cabang Jakarta.
3. Menganalisis dan merancang sistem yang akan dibangun.
Perancangan sistem dengan menggunakan metodologi berorientasi object
dengan membuat use case diagram, class diagram, sequence diagram,
ER-Diagram, serta merancang designdatabase dan user interface.
4. Implementasi sistem
5
1.6. Sistematika Penulisan
BAB I PENDAHULUAN
Bab ini membahas latar belakang masalah, rumusan masalah, batasan masalah,
tujuan penelitian, metodologi penelitian, dan sistematika penulisan.
BAB II LANDASAN TEORI
Bab ini membahas mengenai landasan teori yang menjelaskan tentang database,
Distributed Database Management System (DDBMS), database terdistribusi,
replikasi di MySQL, dan partisi di MySQL 5.1.
BAB III ANALISIS DAN PERANCANGAN SISTEM
Bab ini membahas analisis sistem yang lama dan yang akan dibangun serta
perancangan mengenai database dan user interface sistem yang akan dibangun.
BAB IV IMPLEMENTASI SISTEM
Bab ini membahas mengenai penjelasan rinci mengenai proses implementasi
perangkat lunak sesuai dengan analisis dan rancangan yang dikembangkan.
BAB V ANALISIS HASIL
BAB VI KESIMPULAN DAN SARAN
Bab ini membahas kesimpulan yang didapat dari keseluruhan proses pembuatan
BAB II
LANDASAN TEORI
2.1. Database
Database merupakan sekumpulan tabel data yang berisikan informasi
yang saling berhubungan satu sama lain (secara logika), biasanya disusun dalam
urutan tertentu untuk melayani satu atau lebih aplikasi secara optimal. Suatu
database dapat terdiri dari satu tabel saja.
Database dirancang atas dasar pendekatan aplikatif maupun pendekatan
sistem. Pendekatan aplikatif merupakan cara tradisional, dimana database
dirancang hanya untuk memenuhi satu aplikasi tertentu sehingga terdapat
kemungkinan satu data disiapkan dalam beberapa file berbeda untuk memenuhi
aplikasi-aplikasi yang berbeda. Sedangkan database yang dirancang dengan
pendekatan sistem, memberikan suatu database yang dapat dipergunakan untuk
lebih dari satu aplikasi, dengan mengurangi terjadinya kerangkapan data.
Database dapat berperan sebagai landasan bagi sistem informasi untuk
tujuan manajemen dan dapat mempengaruhi proses manajemen di dalam
organisasi, dengan cara menurunkan kendala-kendala penggunaan waktu yang
lama dan ketersediaan informasi.
2.2. Distributed Database Management System (DDBMS)
DBMS terditribusi adalah (Connoly, 2002) sistem perangkat lunak yang
mengijinkan pengolahan database terdistribusi dan membuat transparan
terhadap pemakainya. Sebuah DDBMS terdiri atas sebuah logical database
yang dibagi ke dalam sejumlah partisi. Tiap partisi disimpan pada satu
komputer atau lebih di bawah kontrol sebuah DBMS yang terpisah, dimana
komputer-komputer tersebut terhubung oleh suatu jaringan komunikasi. Tiap
site (tempat) mampu secara mandiri memproses permintaan user yang
membutuhkan akses ke data lokal dan mampu memproses data yang tersimpan
di komputer-komputer lain dalam jaringan tersebut.
2.3. Sistem Database Terdistribusi
2.3.1. Pengertian Sistem Database Terdistribusi
Sistem terdistribusi secara umum dapat diartikan sebagai sekumpulan
komputer-komputer otonomi yang terhubung melalui sebuah jaringan
komunikasi atau jaringan komputer agar terjadi pertukaran informasi
antarkomputer dan kerjasama antara komputer yang satu dengan komputer
yang lain untuk mencapai suatu fungsi.
Database terdistribusi (Conoly, 2002) adalah suatu kumpulan data
bersama yang saling berelasi secara logis, yang secara fisik tersebar di seluruh
9
Sedangkan Sistem Database Terdistribusi adalah kumpulan lokasi
yang masing-masing mengoperasikan sistem database lokal dan juga dapat
mengakses data global. Tiap lokasi memiliki databasenya sendiri-sendiri
sehingga pengguna pada lokasi A dapat mengakses (dan mungkin
memperbarui) data pada lokasi B
2.3.2. Transparansi pada Sistem Terdistribusi
Sistem database terdistribusi menyediakan beberapa tipe transparansi
dalam Distributed DBMS antara lain :
a. Transparansi Distribusi (Distribution Transparency)
User tidak perlu tahu bahwa data didistribusi, user merasakan databasenya
sebagai database tunggal
1. Transparansi lokasi (location transparency), yang artinya bahwa
user tidak perlu tahu pada lokasi mana potongan data tersimpan, akan
tetapi user harus tahu bagaimana data di fragmentasi.
2. Transparansi fragmentasi (fragmentation transparency) artinya user
dapat melakukan semua akses seakan-akan relasi tidak terfragmentasi
(data merupakan satu kesatuan utuh kembali) dengan kata lain user
tidak perlu tahu bahwa data di fragmentasi dan user tidak perlu
menspesifikasikan nama-nama fragment dan lokasi-lokasi datanya.
diberikan dapat dibagi-bagi menjadi potongan-potongan data
(fragment) untuk keperluan penyimpanan fisik.
3. Transparansi replikasi (replication tranparency) artinya user tidak
perlu tahu replikasi terhadap fragment-fragment, objek logikal yang
diberikan dapat ditampilkan pada level fisik dengan beberapa salinan
(replika) yang berbeda dari objek tersimpan yang sama, pada beberapa
sisi yang berbeda. Meskipun demikian mungkin sebuah sistem tidak
memiliki location tranparency tetapi memiliki replication
tranparency. Sehingga dapat dicatat bahwa transparansi lokasi,
fragmentasi dan replikasi secara bersamaan menyebabkan sistem
terdistribusi seakan-akan merupakan sistem terpusat dalam pandangan
user.
4. Transparansi Pemetaan Lokal (Local Mapping Transparency)
User harus menspesifikasikan baik nama-nama fragment maupun
lokasi item-item data.
5. Transparansi Penamaan (Naming Transparency)
Seperti database terpusat ataupun database terdistribusi harus
memiliki sebuah nama unik. Tidak boleh ada 2 site membuat sebuah
11
b. Transparansi Tranksaksi (Transaction Transparency)
Semua transaksi terdistribusi tetap menjaga konsistensi dan integritas
database terdistribusi, selain itu DDBMS juga harus memastikan
sinkronisasi subtransaksi-subtransaksi dengan transaksi lokal tetapi juga
subtransaksi-subtransaksi dengan transaksi global
1. Transparansi Concurrency (Concurrency Transparency)
Semua transaksi yang dilaksanakan bersamaan (baik terdistribusi
maupun tidak terdistribusi) sama seperti jika transaksi tersebut
dieksekusi pada satu waktu dalam urutan serial.
2. Transparansi Kegagalan (Failure Transparency)
Menjamin atomicity dari global transactions yang berarti memastikan
bahwa subtransaksi global transaction apakah semua commit atau
semua abort.
c. Transparansi Unjuk Kerja(Performance Transparency)
Sebuah DDBMS harus memiliki unjuk kerja seperti DBMS terpusat,
diharapkan sistem tidak mengalamai degradasi/unjuk kerja yang menurun
karena sistem memiliki artitektur terdistribusi.
d. Transparansi DBMS(DBMS Transparency)
2.3.3 Tujuan Sistem Database Terdistribusi
Tujuan utama dari distribusi database adalah untuk memberikan
kemudahan akses data untuk para user di berbagai tempat. Dalam
perkembangannya sistem terdistribusi telah mengalami perubahan-perubahan
untuk memenuhi tujuan dan sasaran dari sistem terdistribusi antara lain :
1. Mendukung perkembangan dari aplikasi dalam jaringan komputer.
2. Konsistensi pelayanan dalam jaringan.
3. Perbaikan pelayanan dalam hal respon time dan availability.
2.4. Replikasi di MySQL
Dalam replikasi single-master, server master akan menulis update ke
binary log filenya dan menjaga index dari file tersebut untuk tetap berada pada
rotasi log (log rotation). Binary log file akan mengirmkan record yang diupdate
ke berbagai server slave. Ketika slave terhubung dengan master, slave akan
memberitahu master posisi slave yang membaca log yang berhasil diupdate
terakhir. Slave menerima berbagai record yang diupdate, kemudian memblok
dan menunggu master untuk mengetahui update yang terbaru.
Replikasi memungkinkan data dari satu MySQL database server (master)
untuk direplikasi ke satu atau lebih MySQL database server (slave). Replikasi
bersifat asynchronous, dimana slave tidak harus terhubung secara permanen
untuk menerima data terbaru dari master, yang berarti data terbaru tetap dapat
13
pengaturan yang dilakukan, replikasi dapat dilakukan pada semua database,
beberapa database yang dipilih, atau bahkan beberapa tabel yang dipilih dalam
sebuah database.
Replikasi multiple-master mungkin untuk dilakukan di MySQL, tetapi
akan menimbulkan banyak masalah, tidak seperti penggunaan replikasi
single-master.
Target penggunaan replikasi di MySQL diantaranya adalah:
• Solusi berskala besar
Menyebarkan data melalui beberapa slave untuk meningkatkan unjuk
kerja. Dalam hal ini, semua write dan update berada pada master server.
• Keamanan data
Karena data direplikasi pada slave, dan slave dapat memberhentikan
proses replikasi, maka hal tersebut memungkinkan untuk menjalankan
servis backup tanpa merusak data master.
• Analitycs
Data dapat dibuat pada master ketika analisis informasi dapat mengambil
alih slave tanpa mempengaruhi unjuk kerja master
• Distribusi data jarak jauh
Jika kantor cabang akan bekerja dengan copy dari data utama, maka dapat
digunakan replikasi untuk membuat local copy dari data utama tanpa
2.5. Partisi di MySQL 5.1
2.5.1. Jenis – Jenis Partisi di MySQL 5.1
• Range Partitioning
Pada tabel yang dipartisi menggunakan range partitioning, akan berisi
baris dimana nilai expression sesuai dengan nilai range yang diberikan.
Range harus saling berurutan, tetapi tidak overlapping.
• List Partitioning
Dalam list partitioning setiap partisi didefinisikan dan dipilih berdasarkan
keanggotaan dari sebuah kolom dari suatu daftar.
• Hash Partitioning
Dalam hash partitioning yang harus dilakukan hanyalah
menspesifikasikan expression yang akan dipartisi dan jumlah partisinya.
Untuk menyimpan suatu record pada tabel yang dipartisi, hash
partitioning menggunakan algoritma modulus
• Linear Hash Partitioning
Linear hash partitioning merupakan perluasan dari hash partitioning yang
menggunakan algoritma lebih kompleks untuk menentukan penyimpanan
suatu record pada tabel yang dipartisi, yaitu algoritma powers-of-two.
• Key Partitioning
Dalam key partitioning tabel akan dipartisi berdasakan key, baik primary
15
2.5.2. Aturan dan Batasan Partisi di MySQL 5.1
Adapun beberpa aturan dan batasan dalam penggunaan partisi di
MySQL 5.1 adalah sebagai berikut :
• Jika membuat tabel dengan jumlah partisi yang besar, maka akan
muncul pesan kesalahan seperti Error code 24: Too many open
files
• Tabel yang dipartisi tidak mendukung foreign key
• Tabel yang dipartisi tidak mendukung FULLTEXT indexes
• Tabel yang dipartisi tidak mendukung GEOMETRY columns
• Pada MySQL 5.1.8, tabel temporari tidak dapat dipartisi
• Tabel yang menggunakan MERGEstorage engine tidak dapat dipartisi.
• Semua tabel yang dipartisi dan di subpartisi harus menggunakan storage
BAB III
ANALISIS DAN PERANCANGAN SISTEM
3.1. Analisis Sistem
3.1.1. Gambaran Umum Sistem Lama
Sistem informasi personal accident yang digunakan di PT. Asuransi
Umum Sarana Lindung Upaya merupakan suatu sistem yang menangani
proses yang berkaitan dengan asuransi personal accident antara lain
pembuatan polis, pengajuan klaim, pembuatan agenda polis, pembuatan
agenda klaim.
Adapun prosedur pengajuan polis asuransi personal accident yang
dilakukan di kantor cabang Jakarta adalah sebagai berikut :
1. Karyawan yang bekerja pada suatu perusahaan (pihak tertanggung)
mengajukkan kredit pada sebuah bank yang bekerjasama dengan PT.
Asuransi Umum Sarana Lindung Upaya. Dengan demikian karyawan
tersebut akan mendapatkan asuransi personal accident dengan jangka
waktu sesuai dengan jangka waktu pengajuan kredit.
2. Pihak bank meminta PT. Asuransi Umum Sarana Lindung Upaya kantor
cabang Jakarta untuk dibuatkan polis.
17
3. PT. Asuransi Umum Sarana Lindung Upaya kantor cabang Jakarta
membuatkan polis asuransi personal accident
4. Dari polis-polis yang masuk dapat dibuatkan agenda polis (daftar peserta
asuransi).
Jika pihak tertanggung mengalami PHK atau meninggal dunia karena
sakit atau karena kecelakaan, maka dapat mengajukan klaim dengan prosedur
yang dilakukan di kantor cabang Jakarta adalah sebagai berikut :
1. Pihak bank melaporkan klaim yang diajukan oleh pihak tertanggung.
2. PT. Asuransi Umum Sarana Lindung Upaya kantor cabang Jakarta
membuatkan agenda klaim.
3. Kemudian membuat laporan klaim sementara atau Preliminary Loss
Advice (PLA) yang selanjutnya dikirimkan ke Reasuransi yang telah
ditunjuk pada awal pembuatan polis.
4. Setelah Reasuransi menyetujui PLA yang dikirimkan, maka dibuatkan
laporan klaim pasti atau Definite Loss Advice (DLA) yang dikirimkan ke
Reasuransi yang telah ditunjuk.
5. Reasuransi membayarkan klaim dan kemudian kantor cabang Jakarta
kemudian membayarkan ke pihak Bank yang mengajukan klaim. Jika
Reasuransi belum membayarkan klaim, maka data-data klaim termasuk
3.1.2. Orang Yang Terlibat Dalam Sistem
Dalam sistem informasi asuransi personal accident melibatkan enam
orang aktor, yaitu:
1. Admin
Orang yang bertanggung jawab penuh untuk mengelola sistem ini,
termasuk memberikan akses bagi aktor lain.
2. Karyawan Bagian Teknik
Orang yang menangani data-data pembuatan polis.
3. Karyawan Bagian Klaim
Orang yang menangani data-data yang berhubungan dengan klaim.
4. Kepala Bagian
Orang yang bertanggung jawab terhadap data-data polis dan klaim
asuransi personal accident yang masuk ke kantor pusat.
5. Kepala Cabang
Kepala Cabang bertanggung jawab di kantor cabang dan berwenang dalam
menyetujui suatu klaim yang masuk.
6. Kepala Divisi
Orang yang mengawasi dan melihat data-data polis atau klaim yang
19
3.1.3. Analisis Masalah
Permasalahan yang timbul adalah ketika kantor cabang Jakarta harus
mengirimkan berkas-berkas polis dan klaim ke kantor pusat Semarang. Pada
PT. Asuransi Umum Sarana Lindung Upaya seluruh pengiriman
berkas-berkas cabang ke kantor pusat, masih menggunakan jasa pos.
3.1.4. Gambaran Umum Sistem Baru
Untuk menangani permasalahan di atas, maka akan dibuat sebuah
sistem baru yang menerapkan teknologi database terdistribusi dengan
menggunakan teknologi replikasi dan partisi.
Penggunaan teknologi replikasi akan mendistribusikan data polis dan
klaim yang baru ke server kantor pusat Semarang dari kantor cabang Jakarta.
Dengan menggunakan teknologi ini, maka pengiriman data dari kantor cabang
ke kantor pusat tidak lagi dilakukan dengan menggunakan jasa pos.
Sedangkan penggunaan teknologi partisi akan lebih memudahkan dalam
mengelola data.
3.1.5. Desain Arsitektur Replikasi
Di setiap kantor cabang dan kantor pusat akan memiliki sebuah server
yang saling terhubung satu dengan yang lain dalam suatu jaringan. Teknologi
replikasi yang akan digunakan adalah replikasi master-slave. Sedangkan
Gambar arsitektur desain replikasi dan partisi data polis antara server kantor
pusat Semarang dan cabang Jakarta terlihat pada Gambar 3.1.
Gambar 3.1 Desain Arsitektur Replikasi dan Partisi
Pada gambar di atas database server pada kantor pusat Semarang akan
menjadi slave, sedangkan database server yang terdapat di kantor cabang,
contohnya Jakarta, akan menjadi master. Adapun data-data yang terdapat pada
kantor pusat akan berisi semua data yang merupakan hasil replikasi dari
21
dengan pembuatan polis dan klaim yang akan terdapat dalam database sesuai
dengan nama kantor. Pada gambar di atas dapat dilihat pada slave terdapat
sebuah database, yaitu jakarta. Nantinya akan pada master akan terdapat dua
buah database, yaitu database semarang dan jakarta. Database semarang
akan berisi data – data pembuatan polis dan klaim pada kantor pusat
semarang. Sedangkan database jakarta merupakan data-data hasil replikasi
3.1.6. Use Case Diagram
3.1.6.1. Use Case Diagram Admin
23
3.1.6.1.1. Use Case Diagram Admin Sub Proses Pengaturan Data
3.1.6.1.2. Use Case Diagram Admin Sub Proses Pembuatan Polis
25
3.1.6.1.3. Use Case Diagram Admin Sub Proses Pengajuan Klaim
3.1.6.2. Use Case Diagram Karyawan Bagian Teknik
27
3.1.6.3. Use Case Diagram Karyawan Bagian Klaim
3.1.6.4. Use Case Diagram Kepala Bagian
3.1.6.4.1. Use Case Diagram Kepala Bagian Teknik
29
3.1.6.4.2. Use Case Diagram Kepala Bagian Klaim
3.1.6.5. Use Case Diagram Kepala Cabang
31
3.1.6.6. Use Case Diagram Kepala Divisi
3.2. Desain Sistem
3.2.1. Sequence Diagram
Proses Memasukkan Data Bank
: form tambah bank
: Admin : l ayar bank : bank kontrol : bank
tam bah_bank()
tam bah_bank()
jalankan form tambah bank
tam pilkan form tambah bank mas ukkan data bank baru
lakukan tambah data bank s im pan data bank
Proses Mengedit Data Bank
: Admin : l ayar bank : bank kontrol : bank : form edit bank
edit_bank()
edit_bank()
jalankan form edit bank
tam pilkan form edit bank
masukkan data edit bank
lakukan edit data bank
33
Proses Menambah Data Reasuransi
: Admin : layar reasuransi : reasuransi kontrol : reasuransi : form tambah reasuransi
tambah_reasuransi()
tambah_reasuransi()
jalankan form tambah reasuransi
tampilkan form tambah reasuransi
masukkan data reasuransi baru
lakukan tambah data reasuransi
simpan data reasuransi
Proses Mengedit Data Reasuransi
: layar reasuransi
: Admin : reasuransi kontrol : reasuransi : form edit reasuransi
edit_reasuransi()
edit_reasuransi()
jalankan form edit reasuransi
tampilkan form edit reasuransi
masukkan data edit reasuransi
lakukan edit data reasuransi
Proses Menambah Data Polis
jalankan form pembuatan polis tampilkan form pembuatan polis
masukkan data pembuatan polis baru tam bah_karyawan()
simpan data karyawan
tambah_pembuatan_polis() simpan data pembuatan polis
Proses Mengedit Data Polis
: form edit pol is
jalankan form edit polis
tam pilkan form edit polis
mem asukkan data edit polis
edit_karyawan()
simpan data karyawan
edit_polis ()
35
Proses Menambah Data Klaim
: Karyawan Bagian Klaim
: l ayar klaim : klaim kontrol : klaim : form tambah klaim
tambah_klaim()
tambah_klaim()
jalankan form tambah klaim
tampilkan form tambah klaim
masukkan data klaim baru
lakukan tambah data klaim
sim pan data klaim
Proses Mengedit Data Klaim
: Karyawan Bagian Klaim
: l ayar klaim : klaim kontrol : klaim : form edit kl aim edit_klaim()
edit_klaim()
jalankan form edit klaim
tampilkan form edit klaim
masukkan data edit klaim
lakukan edit data klaim
Proses Tampil Agenda Polis
ambil username & password
cek username & password
jalankan menu utama
tam pilkan menu utama
kembali ke menu login
username & password val id
3.2.2. Class Diagram
Class diagram untuk sistem yang akan dibangun terlihat pada gambar 3.12.
Konfirmasi Persetujuan Klaim
: Kepal a Divisi : l ayar klaim : klaim kontrol : klaim : form persetuj uan klaim
konfi rmasi persetujuan klai m
jalankan form persetujan klaim
tampilkan form persetujuan klaim
masukkan persetujuan
set status klaim menjadi disetujui
simpan data kl ai m
set status klaim menjadi ditolak
simpan data kl ai m
Klaim disetujui
Klaim ditolak
konfi rmasi persetujuan klai m
Gambar 3.12
Class
3.2.3.1. Entity Relationship Diagram
ER diagram dari sistem yang akan dibangun terlihat pada gambar 3.13.
3.2.3. Desain Database
Tabel-tabel yang terdapat dalam database pada tiap-tiap server adalah tabel
bank, tabel jabatan, tabel kantor, tabel karyawan, tabel klaim, tabel kokndisi_klaim,
tabel kondisi_polis, tabel perusahaan, tabel polis, tabel premi, tabel reasuransi, dan
tabel user.
Gambar 3.13
41
3.2.3.2. Tabel Karyawan
Tabel karyawan digunakan untuk menyimpan data-data karyawan
pemegang polis, dengan format seperti terlihat pada Tabel 3.1.
Tabel 3.1 Tabel Karyawan
Nama Field Tipe Data Ukuran
id_karyawan int -
id_polis int -
nama_karyawan varchar 100
tanggal_lahir date -
perusahaan int -
pertanggungan double -
tgl_mulai date -
tgl_selesai date -
premi decimal 10,2
jml_phk int -
3.2.3.3. Tabel Perusahaan
Tabel perusahaan digunakan untuk menyimpan data-data perusahaan,
dengan format seperti terlihat pada Tabel 3.2.
Tabel 3.2 Tabel Perusahaan
Nama Field Tipe Data Ukuran
id_perusahaan int -
3.2.3.4. Tabel Bank
Tabel bank digunakan untuk menyimpan data-data bank, dengan
format seperti terlihat pada Tabel 3.3.
Tabel 3.3 Tabel Bank
Nama Field Tipe Data Ukuran
id_bank int -
nama_bank varchar 50
alamat_bank varchar 100
3.2.3.5. Tabel Polis
Tabel polis digunakan untuk menyimpan data-data polis, dengan
format seperti terlihat pada Tabel 3.4.
Tabel 3.4 Tabel Polis
Nama Field Tipe Data Ukuran
id_polis int -
id_bank int -
no_polis int -
no_reg varchar 7
tanggal_produksi date -
kondisi int -
reasuransi int -
Nantinya tabel polis akan dipartisi berdasarkan tahun dari tanggal_produksi
43
3.2.3.6. Tabel Klaim
Tabel klaim digunakan untuk menyimpan data-data klaim, dengan
format seperti terlihat pada Tabel 3.5.
Tabel 3.5 Tabel Klaim
Nama Field Tipe Data Ukuran
no_klaim int
tgl_produksi_klaim date -
tertanggung int -
tgl_kejadian date
tempat_kejadian varchar 200
sebab_kejadian int -
jml_klaim int -
no_pla varchar 30
remark_pla varchar 100
tgl_produksi_pla date -
no_pla varchar 30
remark_pla varchar 100
jml_estimasi int -
jml_disetujui int -
tgl_disetujui date
jml_dibayarkan int -
tgl_dibayarkan date
Nantinya tabel klaim akan dipartisi berdasarkan tahun dari
tanggal_produksi_klaim dengan menggunakan jenis partisi range
3.2.3.7. Tabel Premi
Tabel premi digunakan untuk menyimpan data premi, dengan format
seperti terlihat pada Tabel 3.6.
Tabel 3.6 Tabel Premi
Nama Field Tipe Data Ukuran
umur int -
premi double -
phk double -
3.2.3.8. Tabel Kantor
Tabel kantor digunakan untuk menyimpan data mengenai kantor pusat
dan cabang, dengan format seperti terlihat pada Tabel 3.7.
Tabel 3.7 Tabel Kantor
Nama Field Tipe Data Ukuran
id_kantor int -
nama_kantor varchar 30
alamat_kantor varchar 50
3.2.3.9. Tabel Reasuransi
Tabel reasuransi digunakan untuk menyimpan data-data reasuransi,
45
Tabel 3.8 Tabel Reasuransi
Nama Field Tipe Data Ukuran
id_reasuransi int -
nama_reasuransi varchar 20
inisial varchar 3
3.2.3.10.Tabel Kondisi Polis
Tabel kondisi_polis digunakan untuk menyimpan data-data kondisi
suatu polis, dengan format seperti terlihat pada Tabel 3.9.
Tabel 3.9 Tabel Kondisi_polis
Nama Field Tipe Data Ukuran
id_kondisi int
kondisi varchar 45
3.2.3.11.Tabel Kondisi Klaim
Tabel kondisi_klaim digunakan untuk menyimpan sebab terjadinya
suatu klaim, dengan format seperti terlihat pada Tabel 3.10.
Tabel 3.10 Tabel Kondisi_klaim
Nama Field Tipe Data Ukuran
id_kondisi int
3.2.3.12.Tabel Jabatan
Tabel jabatan digunakan untuk menyimpan data-data jabatan yang
selanjutnya akan diguanakan sebagai hak akses untuk setiap pengguna,
dengan format seperti terlihat pada Tabel 3.11.
Tabel 3.11 Tabel Jabatan
Nama Field Tipe Data Ukuran
id_jabatan int
jabatan varchar 50
3.2.3.13.Tabel User
Tabel User digunakan untuk menyimpan data-data user yang dapat
mengakses sistem ini, dengan format seperti terlihat pada Tabel 3.12.
Tabel 3.12 Tabel User
Nama Field Tipe Data Ukuran
id_user int
username varchar 10
password varchar 100
jabatan int -
47
3.2.4. Pemilihan Jenis Partisi
Penggunaan teknologi partisi akan dilakukan pada dua buah tabel,
yaitu pada tabel polis dan tabel klaim pada semua database. Tabel polis akan
dipartisi menggunakan jenis partisi range partitioning berdasarkan pada tahun
dari tanggal pembuatan polis. Sedangkan pada tabel klaim juga akan dipartisi
menggunakan jenis partisi range partitioning berdasarkan pada tahun dari
tanggal pembuatan klaim.
Pemilihan penggunaan range partitioning dikarenakan, dalam range
partitioning dapat menangani data yang memiliki nilai expression yang tidak
sesuai dengan nilai expression yang telah ditentukan. Hal tersebut
dikarenakan penggunaan operator kurang dari (less then (<)) serta
penggunaan maxvalue. Penggunaan operator kurang dari (less then (<)) dapat
memungkinkan data yang memiliki nilai expression lebih kecil dari nilai
expression pada partisi pertama, akan disimpan dalam partisi pertama.
Sedangkan penggunaan maxvalue sebagai nilai expression pada partisi
terakhir memungkinkan data yang memiliki nilai expression lebih besar dari
3.2.5. Desain User Interface
3.2.5.1. Desain Input
3.2.5.1.1. Form Login
Gambar 3.14 Form Login
3.2.5.1.2. Form Setting Koneksi
Gambar 3.15 Form Setting Koneksi
49
3.2.5.1.3. Form Menu Utama
Gambar 3.16 Form Menu Utama
Gambar 3.17. Form Agenda Polis
3.2.5.1.5. Form Menambah Agenda Polis
Gambar 3.18. Form Menambah Agenda Polis
51
Gambar 3.19. Form Mengupdate Agenda Polis
3.2.5.1.7. Form Agenda Klaim
Gambar 3.20. Form Agenda Klaim
Gambar 3.21. Form Menambah Agenda Klaim
3.2.5.1.9. Form Mengupdate Agenda Klaim
Gambar 3.22. Form Mengupdate Agenda Klaim
53
Gambar 3.23. Form PLA
3.2.5.1.11.Form DLA
Gambar 3.24. Form DLA
Gambar 3.25. Form Persetujuan Klaim
3.2.5.1.13.Form Outstanding Klaim
Gambar 3.26. Form Outstanding Klaim
55
Gambar 3.27. Form Setting Bank
3.2.5.1.15.Form Setting Kondisi
Gambar 3.28. Form Setting Kondisi
Gambar 3.29. Form Setting Premi
3.2.5.1.17.Form Setting Reasuransi
Gambar 3.30. Form Setting Reasuransi
57
Gambar 3.31. Form Setting User
3.2.5.1.19.Form Proses List
Gambar 3.32. Form Proses List
3.2.5.2. Desain Output
Gambar 3.33. Laporan Agenda Klaim
59
Pada bab ini akan dibahas bagaimana mengimplementasikan sistem dari
tahap analisis dan desain ke dalam bahasa pemrograman. Sistem ini dibuat dengan
spesifikasi perangkat lunak sebagai berikut.
1. Sistem Operasi Microsoft Windows XP Professional SP 2.
2. IDE NetBeans 5.5.
3. Database MySQL 5.1.19
4. Bahasa Pemrograman J2SE.
5. iReport 2.0.0
4.1. Implementasi Replikasi
Sistem ini dibangun dengan menggunakan teknologi replikasi
master-slave, dimana database server kantor cabang jakarta merupakan
master dan database server kantor pusat semarang merupakan slave.
Adapun langkah – langkah proses implementasi replikasi adalah sebagai
berikut:
1. Membuat database jakarta dan semarang.
2. Membuat user slu.
3. Membuat tabel – tabel yang dibutuhkan untuk membangun sistem
ini, yaitu tabel bank, tabel jabatan, tabel kantor, tabel karyawan, tabel
60
klaim, tabel kondisi_klaim, tabel kondisi_polis, tabel perusahaan,
tabel polis, tabel premi, tabel reasuransi, dan tabel user. Dimana pada
tabel polis dan klaim akan dibangun dengan menggunakan teknologi
partisi.
4. Mengatur konfigurasi untuk database server master.
5. Mengatur konfigurasi untuk database server slave.
6. Menjalankan replikasi.
4.1.1. Membuat Database Jakarta dan Semarang
Pada database server jakarta dibuat database jakarta dengan
menggunakan sintaks SQL sebagai berikut:
create database ‘jakarta’
Sedangkan pada database server semarang dibuat database
semarang dengan menggunakan sintaks SQL sebagai berikut:
create database ‘jakarta’
4.1.2. Membuat User Slu
User slu merupakan user yang akan digunakan untuk mengakses
database sistem. Untuk membuat user slu digunakan sintaks SQL sebagai
berikut:
Agar dapat mengakses database sistem dan melakukan replikasi,
maka user slu diberikan privileges dengan menggunakan sintaks SQL
sebagai berikut:
grant all privileges on *.* to 'slu'@'%' identified by 'slu';
4.1.3. Membuat Tabel – Tabel yang Dibutuhkan Untuk Membangun Sistem
4.1.3.1. Tabel Bank
Tabel bank digunakan untuk menyimpan data bank. Tabel bank
dibuat dengan menggunakan sintaks SQL sebagai berikut:
CREATE TABLE `bank` (
`id_bank` int(11) NOT NULL, `nama_bank` varchar(45) NOT NULL,
`alamat_bank` varchar(150) NOT NULL DEFAULT '-' ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.2. Tabel Jabatan
Tabel jabatan digunakan untuk menyimpan data jabatan user.
Tabel jabatan dibuat dengan menggunakan sintaks SQL sebagai berikut:
CREATE TABLE `jabatan` (
`id_jabatan` int(11) NOT NULL AUTO_INCREMENT, `jabatan` varchar(50) NOT NULL,
PRIMARY KEY (`id_jabatan`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.3. Tabel Kantor
Tabel kantor digunakan untuk menyimpan data kantor. Tabel
62
CREATE TABLE `kantor` (
`id_kantor` int(11) NOT NULL, `nama_kantor` varchar(25) NOT NULL,
`alamat_kantor` varchar(100) NOT NULL DEFAULT '-', PRIMARY KEY (`id_kantor`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.4. Tabel Karyawan
Tabel karyawan digunakan untuk menyimpan data karyawan
pemegang polis. Tabel karyawan dibuat dengan menggunakan sintaks
SQL sebagai berikut:
CREATE TABLE `karyawan` (
`id_karyawan` int(11) NOT NULL, `id_polis` int(11) NOT NULL,
`nama_karyawan` varchar(100) NOT NULL, `tgl_lahir` date NOT NULL,
`perusahaan` int(11) NOT NULL, `pertanggungan` int(11) NOT NULL,
`tgl_mulai` date NOT NULL DEFAULT '1000-01-01', `tgl_selesai` date NOT NULL DEFAULT '1000-01-01', `premi` decimal(10,2) NOT NULL,
`jml_phk` int(11) NOT NULL DEFAULT '0' ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.5. Tabel Klaim
Tabel klaim digunakan untuk menyimpan data klaim. Tabel klaim
dibuat dengan menggunakan sintaks SQL sebagai berikut:
CREATE TABLE `klaim` (
`no_klaim` int(11) NOT NULL,
`tgl_produksi_klaim` date NOT NULL, `tertanggung` int(11) NOT NULL, `tgl_kejadian` date NOT NULL,
`tempat_kejadian` varchar(200) NOT NULL, `kondisi_klaim` int(11) NOT NULL,
`jml_klaim` int(11) NOT NULL,
`no_pla` varchar(30) NOT NULL DEFAULT '-', `remark_pla` varchar(100) NOT NULL DEFAULT '-',
`tgl_produksi_pla` date NOT NULL DEFAULT '1000-01-01', `no_dla` varchar(30) NOT NULL DEFAULT '-',
`remark_dla` varchar(100) NOT NULL DEFAULT '-', `jml_estimasi` int(11) NOT NULL,
`jml_dibayarkan` int(11) NOT NULL DEFAULT '0', `tgl_dibayarkan` date NOT NULL DEFAULT '1000-01-01' ) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY RANGE (year(tgl_produksi_klaim)) ( PARTITION p2005 VALUES LESS THAN (2005), PARTITION p2006 VALUES LESS THAN (2006), PARTITION p2007 VALUES LESS THAN (2007), PARTITION p2008 VALUES LESS THAN (2008), PARTITION p2009 VALUES LESS THAN (2009), PARTITION p2010 VALUES LESS THAN (2010), PARTITION p2011 VALUES LESS THAN MAXVALUE );
4.1.3.6. Tabel Kondisi Klaim
Tabel kondisi klaim digunakan untuk menyimpan data penyebab
terjadinya klaim. Tabel kondisi klaim dibuat dengan menggunakan
sintaks SQL sebagai berikut:
CREATE TABLE `kondisi_klaim` (
`id_kondisi` int(11) NOT NULL AUTO_INCREMENT, `kondisi` varchar(50) NOT NULL,
PRIMARY KEY (`id_kondisi`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.7. Tabel Kondisi Polis
Tabel kondisi polis digunakan untuk menyimpan data kondisi
polis. Tabel kondisi polis dibuat dengan menggunakan sintaks SQL
sebagai berikut:
CREATE TABLE `kondisi_polis` (
`id_kondisi` int(11) NOT NULL AUTO_INCREMENT, `kondisi` varchar(45) NOT NULL,
PRIMARY KEY (`id_kondisi`)
64
4.1.3.8. Tabel Perusahaan
Tabel perusahaan digunakan untuk menyimpan data perusahaan
tempat karyawan pemegang polis bekerja. Tabel perusahaan dibuat
dengan menggunakan sintaks SQL sebagai berikut:
CREATE TABLE `perusahaan` (
`id_perusahaan` int(11) NOT NULL AUTO_INCREMENT, `nama_perusahaan` varchar(25) NOT NULL,
PRIMARY KEY (`id_perusahaan`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.9. Tabel Polis
Tabel polis digunakan untuk menyimpan data polis. Tabel polis
dibuat dengan menggunakan sintaks SQL sebagai berikut:
CREATE TABLE `polis` (
`id_polis` int(11) NOT NULL, `id_bank` int(11) NOT NULL, `no_polis` int(11) NOT NULL, `no_reg` varchar(7) NOT NULL, `tgl_produksi` date NOT NULL,
`kondisi` int(11) NOT NULL DEFAULT '1', `reasuransi` int(11) NOT NULL DEFAULT '109' ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (year(tgl_produksi))( PARTITION p2005 VALUES LESS THAN (2005), PARTITION p2006 VALUES LESS THAN (2006, PARTITION p2007 VALUES LESS THAN (2007), PARTITION p2008 VALUES LESS THAN (2008), PARTITION p2009 VALUES LESS THAN (2009), PARTITION p2010 VALUES LESS THAN (2010), PARTITION p2011 VALUES LESS THAN MAXVALUE );
4.1.3.10.Tabel Premi
Tabel premi digunakan untuk menyimpan data premi. Tabel premi
CREATE TABLE `premi` ( `umur` int(11) NOT NULL,
`jangka_waktu` int(11) NOT NULL, `premi` decimal(10,2) NOT NULL, `phk` decimal(10,2) NOT NULL, PRIMARY KEY (`umur`,`jangka_waktu`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.11.Tabel Reasuransi
Tabel reasuaransi digunakan untuk menyimpan data reasuransi.
Tabel reasuransi dibuat dengan menggunakan sintaks SQL sebagai
berikut:
CREATE TABLE `reasuransi` (
`id_reasuransi` int(11) NOT NULL, `nama_reasuransi` varchar(25) NOT NULL, `inisial` varchar(3) NOT NULL DEFAULT '-', PRIMARY KEY (`id_reas`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
4.1.3.12.Tabel User
Tabel user digunakan untuk menyimpan data user. Tabel user
dibuat dengan menggunakan sintaks SQL sebagai berikut:
CREATE TABLE `user` (
`id_user` int(11) NOT NULL AUTO_INCREMENT, `kantor` int(11) NOT NULL,
`username` varchar(15) NOT NULL, `password` varchar(150) NOT NULL, `jabatan` int(11) NOT NULL, PRIMARY KEY (`id_user`),
UNIQUE KEY `username` (`username`), KEY `FK_user_kantor` (`kantor`), KEY `FK_user_jabatan` (`jabatan`),
CONSTRAINT `FK_user_jabatan` FOREIGN KEY (`jabatan`) REFERENCES `jabatan` (`id_jabatan`),
CONSTRAINT `FK_user_kantor` FOREIGN KEY (`kantor`) REFERENCES `kantor` (`id_kantor`)
66
4.1.4. Mengatur Konfigurasi Untuk Database Server Master
Agar replikasi dapat berjalan, maka master harus memiliki binary
log yang berfungsi untuk pertukaran data antara master dan slave. Pada
setiap server yang termasuk dalam sebuah grup replikasi juga harus
memiliki server-id yang merupakan bilangan integer positif unik yang
dapat dipilih dan ditentukan sendiri. Setiap server-id digunakan untuk
mengidentifikasi setiap server yang terdapat pada sebuah grup replikasi.
Untuk menambahkan binary log dan server-id pada master
dilakukan dengan mengubah file konfigurasi my.ini atau my.cnf server
master pada bagian [mysqld]. Pada sistem ini master menggunakan
jakarta-bin untuk nama dari binary log dan server-id diberi nilai 1,
sehingga ditambahkan sintaks sebagai berikut:
[mysqld]
log-bin=jakarta-bin server-id=1
Sedangkan untuk melihat status replikasi master digunakan sintaks
sebagai berikut:
show master status;
4.1.5. Mengatur Konfigurasi Untuk Database Server Slave
Selain memiliki server-id yang unik, pada slave juga harus
memiliki relay log index yang merupakan file dari SQL thread yang
sedang membaca dan mengeksekusi data – data replikasi. Penamaan dari
server slave dengan diikuti “-relay-bin.index”. Pada file konfigurasi
my.ini atau my.cnf server slave juga dapat ditambahkan database yang
akan direplikasi atau tabel-tabel yang akan direplikasi.
Pada sistem ini, slave memberi nilai 2 untuk server-id. Sedangkan
nama konputer yang digunakan untuk server slave adalah “latih03”,
sehingga nama untuk relay log index-nya adalah “latih03-relay-bin.index”.
Karena hanya akan mereplikasi satu database, yaitu database jakarta,
maka ditambahkan sintaks sebagai berikut:
[mysqld] server-id=2
relay-log-index=latih03-relay-bin.index replicate-do-db=jakarta
Setelah melakukan pengaturan konfigurasi replikasi untuk master
dan slave, maka parameter yang digunakan server slave untuk
berkomunikasi dengan server master harus diubah dengan menjalankan
sintaks berikut pada server slave:
change master to
master_host=’172.21.205.34’,
Dari sintaks di atas, dapat terlihat bahwa master_host merupakan
hostname dari master. Sedangkan untuk master_user, master_password
dan master_port merupakan user, password,dan port yang digunakan oleh
68
yang terdapat pada master. Hal itu dapat ditemukan dengan menjalankan
sintaks berikut pada master:
show master status;
4.1.6. Menjalankan Replikasi
Setelah mengatur konfigurasi pada server master dan slave, maka
replikasi dapat dijalankan dengan menjalankan sintaks berikut pada slave:
start slave;
Untuk mengetahui status dari slave, maka dijalankan sintaks
berikut pada slave:
show slave status;
4.2. Koneksi Ke Database MySQL
Koneksi pada sistem ini menggunakan teknologi JDBC (Java
Database Connectivity). Untuk mempermudah pengaturan
parameter-parameter server, database, user, dan port yang digunakan, maka data-data
tersebut disimpan dalam dokumen conn.acd. Data – data tersebut adalah
sebagai berikut:
Angka 1 merupakan pengaturan untuk database slave dengan
menggunakan teknologi replikasi. Jika tidak ingin menggunakan teknologi
replikasi, maka angka tersebut akan bernilai 0. Sedangkan jika angka
tersebut bernilai 2, maka merupakan pengaturan untuk database master.
Tiga baris setelah angka 1 merupakan pengaturan untuk database slave.
Sedangkan tiga baris terakhir merupakan pengaturan untuk database
master.
4.3. Implementasi User Interface 4.3.1. Form Login
Form login merupakan form yang pertama kali tampil ketika
program dijalankan pertama kali. Form ini berfungsi untuk dapat masuk ke
dalam sistem jika username dan password yang diberikan sesuai. Form
login dapat dilihat pada Gambar 4.1
Gambar 4.1 Form Login
4.3.2. Form Setting Koneksi
Form setting koneksi akan tampil ketika user menekan gambar
70
digunakan database server pada master dan slave. Form setting koneksi
dapat terlihat pada Gambar 4.2
Gambar 4.2 Form Setting Koneksi
4.3.3. Form Menu Utama
Form menu utama merupakan form utama dari aktivitas program
ini. Pada form menu utama berisi berbagai menu sesuai dengan jabatan
yang dimiliki oleh user. Selain itu, pada form menu utama juga terdapat
sebuah panel yang dibagi empat untuk menampilkan keterangan, waktu
akses, koneksi database, serta waktu hari ini. Form menu utama dapat
Gambar 4.3 Form Menu Utama
Untuk menampilkan menu – menu pada form menu utama
ditentukan dengan jabatan yang dimiliki oleh user,yaitu:
1. Admin
Menu yang ditampilkan, yaitu menu polis, klaim, setting, log out, dan
proses.
2. Karyawan Bagian Klaim
Menu yang ditampilkan adalah menu klaim, setting, log out, dan
proses.
3. Karyawan Bagian Teknik
72
4. Kepala Bagian Klaim
Menu yang ditampilkan adalah menu polis, log out, dan proses.
5. Kepala Bagian Teknik
Menu yang ditampilkan adalah menu polis, log out, dan proses.
6. Kepala Cabang dan Kepala Divisi
Menu yang ditampilkan adalah menu polis, klaim, log out, dan proses.
4.3.4. Form Agenda Polis
Form agenda polis merupakan form yang menampilkan semua data
polis berdasarkan bulan dan tahun pembuatan polis serta kantor yang
dipilih. Form agenda polis dapat dilihat pada Gambar 4.4.
4.3.5. Form Menambah Agenda Polis
Form menambah agenda polis merupakan form yang berfungsi
untuk menambah data polis dan data peserta polis. Form menambah
agenda polis dapat dilihat pada Gambar 4.5.
Gambar 4.5 Form Menambah Agenda Polis
4.3.6. Form Mengupdate Agenda Polis
Form mengupdate agenda polis merupakan form yang berfungsi
untuk mengganti, menghapus data polis dan menambah, mengganti,
menghapus data peserta polis. Form ini akan tampil jika melakukan double
klik pada tabel pada form agenda polis. Atau dapat juga dengan memilih
74
kemudian memilih tombol DETAILS. Form mengupdate agenda polis
dapat dilihat pada Gambar 4.6.
Gambar 4.6. Form Mengupdate Agenda Polis
4.3.7. Form Agenda Klaim
Form agenda klaim merupakan form yang menampilkan semua
data klaim berdasarkan bulan dan tahun pembuatan klaim serta kantor
Gambar 4.7. Form Agenda Klaim
4.3.8. Form Menambah Agenda Klaim
Form menambah agenda klaim merupakan form yang berfungsi
untuk menambah data klaim. Form menambah agenda klaim dapat dilihat
