BAB 4
PERANCANGAN DAN IMPLEMENTASI
4.1 Perancangan Basisdata
Perancangan basisdata ini bertujuan supaya dapat membantu memecahkan permasalahan yang dihadapi oleh PT Asuransi Jiwasraya. Perancangan basisdata terdiri dari 3 (tiga) tahap perancangan yaitu :
1. Perancangan basisdata konseptual 2. Perancangan basisdata logikal 3. Perancangan basisdata fisikal
4.1.1 Perancangan Basisdata Konseptual
Perancangan basisdata konseptual terdiri dari 6 (enam) tahap perancangan yaitu :
1. Identifikasi tipe entity 2. Identifikasi tipe relationship
3. Identifikasi atribut dan domain atribut 4. Menentukan candidate key dan primary key 5. Cek redudansi sistem
6. Validasi model konseptual terhadap transaksi
Berikut ini penjelasan tahapan perancangan basisdata konseptual sebagai berikut:
94
4.1.1.1 Identifikasi Tipe Entity
Hubungan anatara semua entity – entity dapat dilihat pada gambar sebagai berikut :
Gambar 4.1 Diagram ER yang menggambarkan relasi antar entity
Tipe entity adalah entitas dasar yang didapatkan dari analisa kebutuhan. Tipe entity yang di identifikasi dari analisa kebutuhan pada PT. Asuransi Jiwasraya dapat dilihat pada tabel berikut ini :
No Entiy Name Description Alias Keterangan
95
No Entiy Name Description Alias Keterangan
1 Klien Entitas yang memberikan data informasi mengenai klien yang mempunyai polis pada PT Asuransi Jiwasraya
Pemegang Polis Satu pemegang polis mempunyai satu polis
2 ProdukBenefit Entitas yang memberikan informasi tentang produk beserta benefit yang didapat
Produk dan Manfaat
Satu produk bisa
mendapatkan lebih dari satu benefit
3 Polis Entitas yang memberikan informasi mengenai detail asuransi yang diambil oleh pemegang polis
Polis Satu polis
dimiliki oleh satu
pemegang polis 4 HistorisPremi Entitas yang memberikan
informasi tentang historis pelunasan premi dari pemegang polis Catatan premi Satu polis mempunyai banyak historis premi
96
No Entity Name Description Alias Keterangan
5 Kantor Entitas yang memberikan informasi tentang kantor-kantor PT Asuransi Jiwasraya yang telah berdiri sekarang ini
Office Satu kantor
mempunyai banyak karyawan
6 Agen Entitas yang memberikan penjelasan tentang karyawan yang bertugas sebagai agen polis di PT Asuransi Jiwasraya Distributor Agen merupakan bagian dari karyawan
7 Penagih Entitas yang memberikan penjelasan tentang karyawan yang bertugas sebagai penagih dari pembayaran polis
Penagih Penagih merupakan
bagian dari karyawan
8 Beneficiary Entitas yang memberikan penjelasan tentang klien yang diberikan hak polis oleh klien tertanggung dimana ada suatu hubungan yang terjadi diantara keduanya
Ahli waris Klien yang mendapatkan polis dari klien
97
No Entity Name Description Alias Keterangan
9 PolisBenefitPremi Entitas yang memberikan penjelasan tentang polis, produk dan benefit yang didapat serta klaim yang diajukan Polis, produk dan benefitnya Polis dapat didapat dari produk dimana akan mendapatkan benefit sesuai yang diinginkan
Tabel 4.1 Tabel Identifikasi Tipe Entity
4.1.1.2 Identifikasi Tipe Relationship
Tipe relationship adalah hubungan antara semua tipe entity yang telah diidentifkasi dari analisa kebutuhan. Hubungan antara semua tipe entity yang telah diidentifikasikan sebelumnya dapat dilihat pada tabel sebagai berikut :
No Entity Name Multiplicity Relationship Entity Name Multiplicity
1 Klien 1..1 1..1 Memiliki Mempunyai Polis Beneficiary 1..* 0..* 2 Polis 1..1 1..1 Mempunyai Mendapatkan HistorisPremi PolisBenefitPremi 1..* 1..* 3 Kantor 1..1 1..1 Memperkerjakan Memperkerjakan Agen Penagih 1..* 1..*
98 No Entity Name Multiplicity Relationship Entity Name Multiplicity
4 Penagih 1..1 Menagih Polis 1..*
5 Agen 1..1 Menawarkan Polis 1..*
6 ProdukBenefit 1..1 Didapatkan PolisBenefitPremi 1..*
Tabel 4.2 Tabel Identifikasi Tipe Relationship 4.1.1.3 Identifikasi Atribut Dan Domain Atribut
Hubungan antara atribut dan domain atribut yang telah diidentifikasikan dapat dilihat pada tabel berikut ini :
No Nama Entity
Atribut Deskripsi Panjang
dan Tipe Data Null Multi Value 1. Klien noKlien namaKlien kdJenisIdentitas jenisKelamin statusPernikahan tempatLahir tanggalLahir No klien (unik) Nama klien
Kode jenis identitas Jenis kelamin Status pernikahan Tempat lahir Tanggal lahir 7 character 20 variable character 7 character 10varariable character 12 variable character 20 variable character Small Datetime No No No No No No No No No No No No No No
99 No Nama
Entity
Atribut Deskripsi Panjang
dan Tipe Data Null Multi Value kdAgama pekerjaan alamatTetap alamatTagih Kode Agama Pekerjaan Alamat tetap Alamat tagih 7 character 20 variable character 50 variable character 50 variable character No No No Yes No No No No 2. Polis noPolis noSPAJ tanggalSPAJ usiaMasuk tanggalMulai lamaAsuransi tanggalEkspirasi lamaPembayaraPremi akhirBayarPremi kdCaraBayar kdValuta No polis (unik) No SPAJ Tanggal SPAJ Usia saat masuk Tanggal mulai asuransi Lama Asuransi Tanggal ekspirasi Lama pembayaran premi
Akhir bayar premi Kode Cara bayar Kode Valuta 7 character 7 character Datetime integer Datetime integer Datetime integer Datetime 7 character 7 character No No No No No No No No No No No No No No No No No No No No No No
100 No Nama
Entity
Atribut Deskripsi Panjang
dan Tipe Data Null Multi Value indexAwal jumlahUangAsuransi premiStandard premi5TahunPertama premiSetelah5Tahun resiko noPemegangPolis noPembayarPremi kdAgen kdPenagih noBp3 tanggalBp3 pembayaranTerakhir statusPolis statusKlaim Index awal Jumlah uang asuransi Premi standard Premi 5 tahun pertama Premi setelah 5 tahun Resiko No pemegang polis No pembayar premi Kode agen Kode penagih No bp3 Tanggal bp3 Pembayaran terakhir
Status polis saat ini
Status klaim Float integer integer integer integer integer 7 character 7 character 7 character 7 character 7 character Datetime Datetime 10 variable character 20 varchar No No No No No No No No No No No No No No No No No No No No No No No No No No No No No No
101 No Nama
Entity
Atribut Deskripsi Panjang
dan Tipe Data Null Multi Value 3. ProdukB enefit kdProduk kdBenefit nilaiBenefit
Kode produk (unik) Kode benefit (unik) Nilai benefit 7 character 7 character Float No No No No No No 4. Agen kdAgen namaAgen kdKantor alamatAgen
Kode agen (unik) Nama agen Kode kantor Alamat agen 7 character 20 variable character 7 character 50 variable character No No No No No No No No 5. Penagih kdPenagih namaPenagih kdKantor alamatPenagih Kode penagih (unik) Nama penagih Kode kantor Alamat penagih 7 character 20 variable character 7 character 50 variable character No No No No No No No No 6. Kantor kdKantor namaKantor alamatKantor
Kode kantor (unik) Nama kantor Alamat kantor 7 character 50 variable character 50 variable No No No No No No
102 No Nama
Entity
Atribut Deskripsi Panjang
dan Tipe Data Null Multi Value kota noTelp noFax emailKantor statusKantor Kota No telpon No fax Email Status kantor character 50 variable character 15 variable character 15 variable character 50 variable character 25 variable character No No No No No No No No No No 7. Historis Premi noPolis tanggalBooked tanggalBayar premi kuitansi No polis (unik) Tanggal booked (unik) Tanggal bayar Premi Kuitansi 7 character Datetime Datetime integer 3 character No No No No No No No No No No 8. Benefici ary noBeneficiary hubungan No beneficiary (unik) Hubungan klien 7 character 10 variable No No No No
103 No Nama
Entity
Atribut Deskripsi Panjang
dan Tipe Data Null Multi Value noKlien No Klien character 7 character No No 9. PolisBe nefitPre mi noPolis kdProduk kdBenefit premi jatuhTempo tanggalKlaim No polis (unik) Kode produk (unik) Kode benefit (unik) Premi Jatuh tempo Tanggal klaim 7 character 7 character 7 character integer Datetime Datetime No No No No No No No No No No No No
Tabel 4.3 Tabel Identifikasi Atribut Dan Domain Atribut
4.1.1.4 Menentukan Candidate Key dan Primary Key
Setelah atribut – atribut dari masing – masing entity di identifikasi, maka diperlukan untuk menentukan atribut yang menjadi candidate dan primary key. Sebelumnya dapat dilihat pada tabel berikut ini :
Entity Name Candidate Key Primary Key Klien 1. noKlien
2. kdJenisIdentitas 3. namaKlien
104 Entity Name Candidate Key Primary Key Polis 1. noPolis 2. noSPAJ 3. noKlien noPolis ProdukBenefit 1. kdProduk 2. kdBenefit kdProduk kdBenefit Kantor 1. kdKantor 2. namaKantor kdKantor Agen 1. kdAgen 2. namaAgen kdAgen Penagih 1. kdPenagih 2. namaPenagih kdPenagih HistorisPremi 1. noPolis 2. tanggalBooked 1. noPolis 2. tanggalBooked Beneficiary 1. noBeneficiary 2. noKlien noBeneficiary PolisBenefitPremi 1. noPolis 2. kdProduk 3. kdBenefit 4. jatuhTempo 5. tanggalKlaim 1. noPolis 2. kdProduk 3. kdBenefit
105 4.1.1.5 Cek Redudansi Sistem
Dalam ER diagram yang telah dibuat tidak terdapat redudancy.
4.1.1.6 Validasi Model Konseptual Lokal Terhadap Transaksi
Tahap ini bertujuan untuk memastikan model konseptual lokal untuk mendukung transaksi yang dibutuhkan oleh transaksi pemakai. Dalam hal ini digunakan jalur arah transaksi (pathways) yang digambarkan dalam diagram ER untuk memeriksa model konseptual lokal agar mendukung transaksi. Adapun transaksi-transaksi yang ada adalah sebagai berikut :
a. Agen Mengupdate klien
b. Klien mendatangi kantor asuransi untuk melakukan pengisian formulir polis
c. Kantor mengupdate polis d. Polis insert ProdukBenefit
e. ProdukBenefit mengupdate PolisBenefitPremi f. Polis mengupdate PolisBenefitPremi
g. Polis mengupdate HistorisPremi h. Insert Beneficiary untuk Polis i. Update Klien untuk Beneficiary
j. Penagih mengambil surat tagihan untuk klien di kantor
Berdasarkan transaksi tersebut, maka dengan menggunakan diagram ER akan dapat ditentukan pathways dari
106 transaksi yang ada. Transaksi-transaksi tersebut dapat dilihat melalui gambar sebagai berikut :
Gambar 4.2 Model konseptual terhadap transaksi
4.1.2 Perancangan Basisdata Logikal
Perancangan basisdata logikal terdiri dari 4 (empat) tahap perancangan yaitu :
1. Menentukan model logikal data lokal. Adapun dalam tahapan ini terbagi menjadi 9 ( sembilan ) yaitu :
1.1 Strong entiti types 1.2 Weak entiti types
107 1.4 One-to-one (1:1) binary relationship types
1.5 One-to-one (1:1) recursive relationship types 1.6 Superclass/subclass relationship types
1.7 Many-to-many (*:*) binary relationship types 1.8 Complex relationship types
1.9 Multi-valued atribut
2. Validasi model dengan normalisasi 3. Validasi relasi terhadap transaksi 4. Mendefinisikan kendala integrity
Adapun dalam langkah ini terbagi menjadi 4 ( empat ) antara lain : 4.1 Required data
4.2 Attibute domain Constraints 4.3 Entiti integrity
4.4 Referential integrity
Pada tahapan ini model data konseptual yang di bangun pada tahap sebelumnya diperhalus dan dipetakan pada model data logikal. Keseluruhan proses dari pengembangan model data logikal ( logikal data model ) adalah di uji dan juga digunakan teknik normalisasi untuk menguji kebenaran dari model data logikal. Kemudian dari model data logikal lokal akan dikombinakan menjadi model data logikal global tunggal. Adapun langkah – langkah dalam tahapan ini adalah sebagai berikut :
108 4.1.2.1 Menentukan Model Logikal Data Lokal
Tujuan langkah ini adalah membuat relasi untuk model data logikal lokal untuk mempresentasikan entity-entity, relationship – relationship dan atribut – atribut yang telah diidentifikasikan sebelumnya, dalam langkah ini ditentukan primary key dan foreign key dari setiap relasi, dimana seiring dengan pengidentifikasian foreign key maka suatu relasi akan jelas primary key yang menjadi referensinya. Hasil dari langkah ini dapat dilihat dengan menggunakan :
4.1.2.1.1 Strong Entity Types
Strong entity merupakan entiti yang dapat berdiri sendiri.
¾ Klien (noKlien, namaKlien, kdJenisIdentitas, noIdentitas, jenisKelamin, statusPernikahan, tempatLahir, tanggalLahir, kdAgama, pekerjaan, alamatTetap, alamatTagih)
Primary key noKlien
¾ Kantor (kdKantor, namaKantor, alamatKantor, kota, noTelp, noFax, emailKantor, statusKantor)
Primary key kdKantor
¾ ProdukBenefit (kdProduk, kdBenefit, nilaiBenefit) Primary key kdProduk, kdBenefit
¾ Agen (kdAgen, namaAgen, kdKantor, alamatAgen) Primary key kdAgen
109 ¾ Penagih (kdPenagih, namaPenagih, kdKantor,
alamatPenagih)
Primary key kdPenagih 4.1.2.1.2 Weak Entity Types
Weak entity merupakan entiti yang masih bergantung dengan strong entity.
¾ Polis (noPolis, noSPAJ, tanggalSPAJ, usiaMasuk, tanggalMulai, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, caraBayar, kdValuta, indexAwal, jumlahUangAsuransi,
premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko, noPemegangPolis,
noPembayarPolis, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, statusPolis, statusKlaim)
Primary key noPolis
¾ HistorisPremi (noPolis, tanggalBooked, tanggalBayar, premi, kuitansi)
Primary key noPolis, tanggalBooked
¾ Beneficiary (noBeneficiary, hubungan, noKlien) Primary key noBeneficiary, noKlien
¾ PolisBenefitPremi (noPolis, kdProduk, kdBenefit, premi, jatuhTempo, tanggalKlaim)
110 4.1.2.1.3 One-to-many(1:*) binary relationship types Tipe relasi one-to-many dapat terjadi pada pada setiap entiti yang bertansaksi.
Polis (noPolis, noSPAJ, tanggalSPAJ, kdProduk, usiaMasuk, tanggalMulai, noPembayarPolis, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, caraBayar, valuta, indexAwal, jumlahUangAsuransi, premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko, noPemegangPolis, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, usiaPolis, statusPolis, statusKlaim)
Primary key noPolis
Foreign key noPemegangPolis, noPembayarPolis Reference Klien(noKlien) kdAgen References Agen(kdAgen)
kdPenagih References Penagih(kdPenagih) Klien (noKlien, namaKlien, noIdentitas,
jenisKelamin, statusPernikahan, usia, tempatLahir, tanggalLahir, agama, pekerjaan, alamatTetap, alamatTagih, beneficiaryDari, hubungan)
Primary key noKlien
Polis (noPolis, noSPAJ, tanggalSPAJ, kdProduk, usiaMasuk, tanggalMulai, noPembayarPolis, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, caraBayar, valuta, indexAwal, jumlahUangAsuransi, premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko, noPemegangPolis, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, usiaPolis, statusPolis, statusKlaim)
Primary key noPolis
Foreign key noPemegangPolis, noPembayarPolis Reference Klien(noKlien) kdAgen References Agen(kdAgen)
kdPenagih References Penagih(kdPenagih)
HistorisPremi (noPolis, tanggalBooked, tanggalBayar, premi, kuitansi)
Primary key noPolis, tanggalBooked Foreign key noPolis References Polis(noPolis)
Polis (noPolis, noSPAJ, tanggalSPAJ, kdProduk, usiaMasuk, tanggalMulai, noPembayarPolis, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, caraBayar, valuta, indexAwal, jumlahUangAsuransi, premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko, noPemegangPolis, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, usiaPolis, statusPolis, statusKlaim)
Primary key noPolis
Foreign key noPemegangPolis, noPembayarPolis Reference Klien(noKlien) kdAgen References Agen(kdAgen)
kdPenagih References Penagih(kdPenagih)
PolisBenefitPremi (noPolis, noProdukBenefit, premi, jatuhTempo, tanggalKlaim)
Primary key noPolis, noProdukBenefit Foreign key noPolis References Polis(noPolis)
noProdukBenefit References ProdukBenefit(noProdukBenefit)
Kantor (kdKantor, namaKantor, alamatKantor, kota, noTelp, noFax, emailKantor, statusKantor)
Primary key kdKantor
Agen (kdAgen, namaAgen, kdKantor, alamatAgen) Primary key kdAgen
Foreign key kdKantor References Kantor(kdKantor) Kantor (kdKantor, namaKantor, alamatKantor, kota, noTelp, noFax, emailKantor,
statusKantor) Primary key kdKantor
Penagih (kdPenagih, namaPenagih, kdKantor, alamatPenagih) Primary key kdPenagih
Foreign key kdKantor References Kantor(kdKantor) Masukan kdKantor ke dalam Penagih dengan model 1..* mempekerjakan relationship
Masukan kdKantor ke dalam Agen dengan model 1..* mempekerjakan relationship Masukan noPolis ke dalam PolisBenefitPremi dengan model 1..* mendapatkan relationship Masukan noPolis ke dalam HistorisPremi dengan model 1..* mempunyai relationship
Masukan noKlien ke dalam Polis dengan model 1..* memiliki relationship
Gambar 4.3 One-to-many(1:*) binary relationship types
4.1.2.1.4 One-to-one (1:1) binary relationship types
Dalam perancangan ini tidak terdapat One-to-one (1:1) binary relationship types.
4.1.2.1.5 One-to-one (1:1) recursive relationship types Dalam perancangan ini tidak terdapat One-to-one (1:1) recursive
111 4.1.2.1.6 Superclass/subclass relationship types
Dalam perancangan ini tidak terdapat Superclass/subclass relationship types.
4.1.2.1.7 Many-to-many (*:*) binary relationship types Dalam perancangan ini tidak terdapat Many-to-many (*:*)
binary relationship types.
4.1.2.1.8 Complex relationship types
Dalam perancangan ini tidak terdapat complex relationship types.
4.1.2.1.9 Multi-valued atribut
Dalam perancangan ini tidak terdapat multi-valued atribut types.
4.1.2.2 Validasi Model dengan Normalisasi
Menurut Connoly dan Begg (2005,p473), langkah ini bertujuan untuk memvalidasikan model yang telah dibuat dengan menggunakan normalisasi. Proses normalisasi data dimaksudkan untuk menghilangkan redundansi semaksimal mungkin dan meningkatkan kemudahan operasi untuk mengubah, menghapus dan memasukkan data pada suatu basis data. Tahap normalisasi terdiri dari tahapan bentuk normal pertama, bentuk normal kedua yakni menghilangkan partial dependency, dan membuat dalam bentuk normal ketiga yakni menghilangkan transitive dependency.
Pada langkah sebelumnya, telah didapat skema relasi yang telah memenuhi bentuk normal pertama (1NF), normal kedua (2NF) dan
112 normal ketiga (3NF). Akan tetapi, ada beberapa tabel yang masih belum memenuhi syarat 1NF, 2NF, dan 3NF. Berikut adalah langkah-langkah normalisasi menuju bentuk 3NF.
¾ ProdukBenefit 1NF
ProdukBenefit (kdProduk, kdBenefit, namaProduk, medicalStatus, namaBenefit, nilaiBenefit)
2NF
ProdukBenefit (kdProduk, kdBenefit, nilaiBenefit)
Produk (kdProduk, kdBenefit, namaProduk, medicalStatus, namaBenefit)
3NF
ProdukBenefit (kdProduk, kdBenefit, nilaiBenefit) Produk (kdProduk, namaProduk, medicalStatus) Benefit (kdBenefit, namaBenefit)
¾ Klien 1NF
Klien (noKlien, namaKlien, kdJenisIdentitas, noIdentitas, jenisKelamin, statusPernikahan, tempatLahir, tanggalLahir, kdAgama, pekerjaan, alamatTetap, alamatTagih)
113 2NF
Klien (noKlien, namaKlien, kdJenisIdentitas, noIdentitas, jenisKelamin, statusPernikahan, tempatLahir, tanggalLahir, kdAgama, pekerjaan, alamatTetap, alamatTagih)
Identitas (kdJenisIdentitas, jenisIdentitas) 3NF
Klien (noKlien, namaKlien, kdJenisIdentitas, noIdentitas, jenisKelamin, statusPernikahan, tempatLahir, tanggalLahir, kdAgama, pekerjaan, alamatTetap, alamatTagih)
Identitas (kdJenisIdentitas, jenisIdentitas) Agama (kdAgama, Agama)
¾ Polis 1NF
Polis (noPolis, noSPAJ, tanggalSPAJ, usiaMasuk, tanggalMulai, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, kdCaraBayar, kdValuta, indexAwal, jumlahUangAsuransi, premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko, noPemegangPolis, noPembayarPremi, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, statusPolis, statusKlaim)
114 2NF
Polis (noPolis, noSPAJ, tanggalSPAJ, usiaMasuk, tanggalMulai, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, kdCaraBayar, kdValuta, indexAwal, jumlahUangAsuransi, premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko, noPemegangPolis, noPembayarPremi, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, statusPolis, statusKlaim)
Produk (kdProduk, namaProduk, medicalStatus) 3NF
Polis (noPolis, noSPAJ, tanggalSPAJ, usiaMasuk, tanggalMulai, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, kdCaraBayar, kdValuta, indexAwal, jumlahUangAsuransi, premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko, noPemegangPolis, noPembayarPremi, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, statusPolis, statusKlaim)
Produk (kdProduk, namaProduk, medicalStatus) CaraBayar (kdCaraBayar, jenisCaraBayar) Valuta (kdValuta, namaValuta)
115 4.1.2.3 Validasi Relasi terhadap transaksi
Dalam tahap logikal, entiti utama akan mengalami perubahan berkenaan dengan adanya transaksi yang terjadi. Adapun transaksi-transaksi yang ada adalah sebagai berikut :
a. Agen Mengupdate klien
b. Klien mendatangi kantor asuransi untuk melakukan pengisian formulir polis
c. Kantor mengupdate polis d. Polis insert ProdukBenefit
e. ProdukBenefit mengupdate PolisBenefitPremi f. Polis mengupdate PolisBenefitPremi
g. Polis mengupdate HistorisPremi h. Insert Beneficiary untuk Polis i. Update Klien untuk Beneficiary
j. Penagih mengambil surat tagihan untuk klien di kantor
k. Produk dapat meng-update benefit yang ada sesuai kebutuhan pada tabel ProdukBenefit
l. Benefit diinsert pada ProdukBenefit
m. Polis menginsert cara bayar yang telah dipilih oleh Klien n. Identitas diinsert ke dalam tabel Klien
o. Agama diinsert ke dalam tabel Klien p. Valuta diinsert dalam tabel Polis
q. Data penagih ditulis pada polis sebagai bukti telah ditagih asuransinya
116 s. Data agen ditulis pada polis sebagai bukti penawaran produk
asuransi
Gambar 4.4 Model logikal terhadap transaksi
4.1.2.4 Mengidentifikasikan kendala integrity
Langkah ini bertujuan untuk mencegah basisdata dari ketidakkonsitenan. Integritas constraint dibagi menjadi lima bentuk dasar , yakni :
117 4.1.2.4.1 Required Data
Beberapa atribute harus selalu mengandung nilai yang valid, dengan kata lain atribut tidak boleh mengandung nilai null. Contraint ini telah dilakukan pada saat dokumentasi.
4.1.2.4.2 Atribute Domain Constraints
Setiap atribut mempunyai domain atribut mempunyai domain sendiri, yaitu, sekumpulan nilai yang sah untuk suatu atribut. Constraint ini telah ditentukan pada saat ditentukan nilai akan dimasukkan dari tipe dan panjang dari suatu atribut.
4.1.2.4.3 Entiti Integrity
Sebuah primary key dari sebuah entiti tidak boleh mengandung nilai null. Setiap tuple harus mengandung sebuah primary key. Constraint ini telah dilakukan pada memilih primary key untuk setiap tipe entiti.
4.1.2.4.4 Referential Integrity
Sebuah foreign key menghubungkan setiap tuple didalam relasi anak kepada tuple dalam relasi induk yang mengandung nilai candidate key yang cocok.
Klien (noKlien, namaKlien, kdJenisIdentitas,
noIdentitas, jenisKelamin, statusPernikahan, tempatLahir, tanggalLahir, kdAgama, pekerjaan, alamatTetap, alamatTagih)
PolisBenefitPremi (noPolis, kdProduk, kdBenefit,
premi, jatuhTempo, tanggalKlaim)
Primary key noPolis, kdProduk, kdBenefit Foreign key noPolis references Polis (noPolis)
118
Primary key noKlien Foreign key kdProduk references Produk
(kdProduk)
Foreign key kdBenefit references Benefit
(kdBenefit)
Kantor (kdKantor, namaKantor, alamatKantor,
kota, noTelp, noFax, emailKantor, statusKantor)
Primary key kdKantor
HistorisPremi (noPolis, tanggalBooked, tanggalBayar, premi, kuitansi)
Primary key noPolis, tanggalBooked
Foreign key noPolis references Polis (noPolis) Polis (noPolis, noSPAJ, tanggalSPAJ, usiaMasuk,
tanggalMulai, lamaAsuransi, tanggalEkspirasi, lamaPembayaranPremi, akhirBayarPremi, kdCaraBayar, kdValuta, indexAwal, jumlahUangAsuransi, premiStandard, premi5TahunPertama, premiSetelah5Tahun, resiko,
noPemegangPolis, noPembayarPremi, kdAgen, kdPenagih, noBp3, tanggalBp3, pembayaranTerakhir, statusPolis, statusKlaim)
Primary key noPolis
Foreign key noPemegangPolis, noPembayarPremi reference Klien(noKlien)
Foreign key kdAgen references Agen (kdAgen) Foreign key kdPenagih references Penagih
(kdPenagih)
ProdukBenefit (kdProduk, kdBenefit ,
nilaiBenefit)
Primary key kdProduk, kdBenefit
Foreign key kdProduk references Produk (kdProduk)
Foreign key kdBenefit references Benefit (kdBenefit)
Produk (kdProduk , namaProduk , medicalStatus) Primary key kdProduk
Beneficiary (noBeneficiary, hubungan, noKlien) Primary key noBeneficiary
Foreign key noKlien references Klien (noKlien) Agen (kdAgen, namaAgen, kdKantor, alamatAgen) Penagih (kdPenagih, namaPenagih, kdKantor,
119
Primary key kdAgen
Foreign key kdKantor references Kantor (kdKantor)
alamatPenagih)
Primary key kdPenagih
Foreign key kdKantor references Kantor (kdKantor)
Benefit (kdBenefit, namaBenefit) Primary key kdBenefit
CaraBayar ( kdCaraBayar, jenisCaraBayar) Primary key kdCaraBayar
Valuta (kdValuta, namaValuta) Primary key kdValuta
Identitas (kdJenisIdentitas, jenisIdentitas) Primary key kdJenisIdentitas
Agama (kdAgama, Agama) Primary key kdAgama
Tabel 4.5 Tabel Referential Integrity
4.1.3 Perancangan Basisdata Fisikal
Perancangan basisdata fisikal terdiri dari 3 (tiga) tahap perancangan yaitu :
1. Menerjemahkan model logikal dalam DBMS
Adapun dalam langkah ini terbagi menjadi 3 ( tiga ) antara lain : 1.1 Pemilihan DBMS
1.2 Rancangan basis relasi 1.3 Rancangan data turunan 2. Representasi fisikal
Adapun dalam langkah ini terbagi menjadi 4 ( empat ) antara lain : 2.1 Analisa transaksi
120 2.3 Pemilihan index
2.4 Estimasi disk space 3. Keamanan
Adapun dalam langkah ini terbagi menjadi 2 ( dua ) antara lain : 3.1 Merancang user view
3.2 Merancang mekanisme keamanan
Tahapan ini merupakan proses untuk menghasilkan sebuah deskripsi dari implementasi basisdata pada media penyimpan dimana mendeskripsikan model logikal dalam DBMS, representasi fisikal, dan keamanan. Adapun secara jelasnya langkah – langkah yang dilakukan dalam tahapan ini dapat dilihat sebagai berikut :
4.1.3.1 Menerjemahkan Model Logikal dalam DBMS
Langkah ini bertujuan untuk menghasillkan skema relasi basisdata dari model data logikal global yang dapat diimplementasikan ke dalam DBMS yang ditargetkan.
Adapun langkah - langkah dalam menerjemahkan model data logikal ke dalam DBMS antara lain :
4.1.3.1.1 Pemilihan DBMS
Pemilihan DBMS dilakukan berdasarkan feasibility analysis, yang mencakup kriteria DBMS yang ditinjau dari segi operasional, teknis, ekonomis, serta penjadwalan. Tabel 4.3 menunjukkan hasil analisis terhadap pemilihan DBMS yang akan digunakan,
121 dengan menyesuaikan terhadap basisdata yang dirancang serta karakteristik sistem yang dimiliki oleh perusahaan. Kriteria Feasibility Faktor Pemberat Kandidat 1 ( SQL Server 2000 EnterpriseEdition) Kandidat 2 ( Oracle 10g ) Operational Feasibility Menggambarkan
sebaik apa sistem akan bekerja dan juga penerimaan solusi yang ditawarkan
30% SQL Server 2000 menempati tempat pertama pada tes TPC-C dengan
Disstributed
Patitional
Viewes-based sistem cluster. Dan juga
SQL Server sudah banyak digunakan sehingga akan lebih mudah untuk diterima Dari segi keamanan Oracle memberikan fungsional yang tinggi, namun dari segi penerimaan Oracle lebih umum digunakan pada perusahaan dengan basisdata yang sangat besar, sehingga perusahaan dengan basisdata yang ridak terlalu
besar akan cenderung untuk
122 Kriteria Feasibility Faktor Pemberat Kandidat 1 ( SQL Server 2000 EnterpriseEdition) Kandidat 2 ( Oracle 10g ) Nilai : 85 memilih DBMS lain yang lebih sesuai Nilai : 80 Technical Feasibility Menilai kematangan teknologi, tingkat keahlian teknis yang dibutuhkan untuk mengembangkan, mengoperasikan dan mengelola DBMS 30% SQL Server 2000 Enterprise Editionsudah cukup lama diluncurkan sehingga kematangan teknologinya tidak perlu diragukan lagi dan juga lebih mudah untuk dikuasai, sehingga tidak diperlukan tingkat keahlian teknis yang terlalu tinggi. Karena bila diperlukan tingkat Oracle 10g bisa dikatakan sebagai produk baru, namun kematangan teknologinya sudah dapat diandalakan. Secara teknis Oracle membutuhkan keahlian yang lebih daripada SQL Server. Namun Oracle ini mendukung
123 Kriteria Feasibility Faktor Pemberat Kandidat 1 ( SQL Server 2000 EnterpriseEdition) Kandidat 2 ( Oracle 10g ) keahlian yang
tinggi maka akan harus dilakukan lagi pelatihan dan hal ini akan menimbulkan biaya tambahan. Namun SQL Server 2000 ini hanya mendukung platform berbasis windows Nilai : 80 semua platform, tidak hanya platform berbasis windows saja. Nilai : 85 Economic Feasibility
Berapa besar biaya yang dibutuhkan dalam menerapakan solusi 30% SQL Server 2000 Enterprise Edition dihargai US$ 19,999 dan harga ini sudah mencakup berbagai fitur OLAP dan Data
Oracle 10g Enterprise Edition
dihargai US$ 40,000 (sama seperti Oracle 9i) namun belum meliputi fitur –
124 Kriteria Feasibility Faktor Pemberat Kandidat 1 ( SQL Server 2000 EnterpriseEdition) Kandidat 2 ( Oracle 10g ) Mining Nilai : 90 fitur manajemen maupun OLAP dan Data Mining.
Bila ingin menginstall fitur – fitur tersebut, maka harus mengeluarkan biaya tambahan lagi Nilai : 80 Schedule Feasibility
Berapa lama waktu yang diperlukan untuk
merancang dan mengimplementasikan solusi 10% Karena tidak membutuhkan keahlian teknis yang terlalu tinggi maka solusi dapat diimplementasikan dalam waktu 5-7 bulan Nilai : 75 Butuh waktu sekitar 9-12 bulan untuk mengimplemantas ikan solusi Nilai : 70
125 Kriteria Feasibility Faktor Pemberat Kandidat 1 ( SQL Server 2000 EnterpriseEdition) Kandidat 2 ( Oracle 10g ) Nilai Total 100% 87 80.5
Tabel 4.6 Tabel Matriks feasibility analysis pemilihan DBMS
4.1.3.1.2 Rancangan Dasar Relasi
Langkah ini bertujuan untuk memutuskan bagaimana merepresentasikan basis relasi yang diidentifikasikan pada model data logikal global ke dalam sasaran DBMS.
Adapun hasil dari pada langkah ini adalah sebagai berikut :
Klien
Domain nomor klien fixed length character string , 7 Domain nama klien variable length character string,20 Domain kode jenis Identitas fixed length character string, 7 Domain nomor identitas variable length character string, 25 Domain jenis Kelamin variable length character string, 10 Domain status pernikahan variable length character string, 12 Domain tempatLahir variable length character string, 20 Domain tanggalLahir small datetime
126
Domain pekerjaan variable length character string, 20 Domain alamat tetap variable length character string, 50 Domain alamat tagih variable length character string, 50
Klien (
noKlien nomor klien NOT NULL,
namaKlien nama klien NOT NULL,
kdJenisIdentitas kode Jenis identitas NOT NULL, noIdentitas nomor Identitas NOT NULL, jenisKelamin jenis kelamin NOT NULL, statusPernikahan status pernikahan NOT NULL,
tempatLahir tempat lahir NOT NULL,
tanggalLahir tanggal lahir NOT NULL,
kdAgama kode agama NOT NULL,
pekerjaan pekerjaan NOT NULL,
alamatTetap alamat tetap NOT NULL,
alamatTagih alamat tagih NOT NULL,
PRIMARY KEY ( noklien ) )
Polis
Domain nomor polis fixed length character string, 7 Domain nomor SPAJ fixed length character string, 7 Domain tanggal SPAJ datetime
127
Domain tanggal mulai datetime Domain lama asuransi integer Domain tanggal ekspirasi datetime Domain lama pembayaran premi intager Domain akhir bayar premi datetime
Domain kode cara bayar variable length character string, 10 Domain kode valuta variable length character string, 10 Domain index awal decimal
Domain jumlah uang asuransi integer Domain premi standard integer Domain premi 5 tahun pertama integer Domain premi setelah 5 tahun integer
Domain resiko integer
Domain nomor pemegang polis fixed length character string, 7 Domain nomor pembayar premi fixed length character string, 7 Domain kode agen fixed length character string, 7 Domain kode penagih fixed length character string, 7 Domain nomor Bp3 fixed length character string, 7 Domain tanggal Bp3 datetime
Domain pembayaran terakhir datetime
Domain status polis variable length characterstring, 10 Domain status klaim variable length character string, 20
Polis (
128
noSPAJ nomor SPAJ NOT NULL,
tanggalSPAJ tanggal SPAJ NOT NULL,
usiaMasuk usia masuk NOT NULL,
tanggalMulai tanggal mulai NOT NULL,
lamaAsuransi lama asuransi NOT NULL, tanggalEkspirasi tanggal ekspirasi NOT NULL, lamaPembayaranPremi lama pembayaran premi NOT NULL, akhirBayarPremi akhir bayar premi NOT NULL, KdCaraBayar kode cara bayar NOT NULL,
KdValuta kode valuta NOT NULL,
indexAwal index awal NOT NULL,
jumlahUangAsuransi jumlah uang asuransi NOT NULL, premiStandard premi standard NOT NULL, premi5TahunPertama premi 5 tahun pertama NOT NULL, premiSetelah5Tahun premi setelah 5 tahun NOT NULL, resiko resiko NOT NULL, noPemegangPolis nomor pemegang polis NOT NULL, noPembayarPremi nomor pembayar polis NOT NULL, kdAgen kode agen NOT NULL, kdPenagih kode penagih NOT NULL, noBp3 nomor Bp3 NOT NULL, tanggalBp3 tanggal Bp3 NOT NULL, pembayaranTerakhir pembayaran terakhir NOT NULL, statusPolis status polis NOT NULL, statusKlaim status klaim NOT NULL,
129
PRIMARY KEY (noPolis),
FOREIGN KEY(KdValuta) REFERENCES Valuta (KdValuta) ON UPDATE CASCADE ON DELETE NO ACTION,
FOREIGN KEY (KdCaraBayar) REFERENCES CaraBayar (KdCaraBayar) ON UPDATE CASCADE ON DELETE NO ACTION, FOREIGN KEY (noPemegangPolis) REFERENCES Klien (noKlien) ON UPDATE CASCADE ON DELETE NO ACTION,
FOREIGN KEY (noPembayarPolis) REFERENCES Klien (noKlien) ON UPDATE CASCADE ON DELETE NO ACTION
)
ProdukBenefit
Domain kode produk fixed length character string, 7 Domain kode benefit fixed length character string, 7
Domain nilai benefit decimal
Produk Benefit (
kdProduk kode produk NOT NULL, kdBenefit kode benefit NOT NULL, nilaiBenefit nilai benefit NOT NULL, PRIMARY KEY (KdProduk),
PRIMARY KEY (KdBenefit),
FOREIGN KEY (KdProduk) REFERENCES Produk (KdProduk) ON UPDATE CASCADE ON DELETE NO ACTION,
130
UPDATE CASCADE ON DELETE NO ACTION )
Agen
Domain kode agen fixed length character string, 7 Domain nama agen variable length character string, 20 Domain kode kantor fixed length character string, 7 Domain alamat agen variable length character string, 50
Agen (
kdAgen kode agen NOT NULL, namaAgen nama agen NOT NULL, kdKantor kode kantor NOT NULL, alamatAgen alamat agen NOT NULL, PRIMARY KEY (KdAgen),
FOREIGN KEY (KdKantor) REFERENCES Kantor (KdKantor) ON UPDATE CASCADE ON DELETE NO ACTION
)
Penagih
Domain kode penagih fixed length character string, 7 Domain nama penagih variable length character string, 20 Domain kode kantor fixed length character string, 7 Domain alamat penagih variable length character string, 50
131
Penagih (
kdPenagih kode penagih NOT NULL namaPenagih nama penagih NOT NULL kdKantor kode kantor NOT NULL alamatPenagih alamat penagih NOT NULL PRIMARY KEY (KdPenagih),
FOREIGN KEY (KdKantor) REFERENCES Kantor (KdKantor) ON UPDATE CASCADE ON DELETE NO ACTION
)
Kantor
Domain kode kantor fixed length character string 7 Domain nama kantor variable length character string 50 Domain alamat kantor variable length character string 50 Domain kota variable length character string 50 Domain nomor telpon variable length character string 15 Domain nomor fax variable length character string 15 Domain email kantor variable length character string 50 Domain status kantor variable length character string 25
Kantor (
kdKantor kode kantor NOT NULL
namaKantor nama kantor NOT NULL
132
kota kota NOT NULL noTelp nomor telpon NOT NULL
noFax nomor faximail NOT NULL
emailKantor email kantor NOT NULL statusKantor status kantor NOT NULL PRIMARY KEY ( kdKantor )
)
Histori Premi
Domain nomor polis fixed length character string 7 Domain tanggal booked datetime
Domain tanggal bayar datetime Domain premi integer
Domain kuitansi fixed length character string 7
Histori Premi (
noPolis nomor polis NOT NULL tanggalBooked tanggal booked NOT NULL tanggalBayar tanggal bayar NOT NULL premi premi NOT NULL kuitansi kuitansi NULL PRIMARY KEY (noPolis),
PRIMARY KEY (tanggalBooked),
FOREIGN KEY (noPolis) REFERENCES Polis (noPolis) ON UPDATE CASCADE ON DELETE NO ACTION
133
Beneficiary
Domain nomor beneficiary fixed length character string 7 Domain hubungan variable length character string 20 Domain nomor klien fixed length character string 7
Benefiaciary (
noBeneficiary noBeneficiary NOT NULL hubungan hubungan NOT NULL
noKlien noKlien NOT NULL PRIMARY KEY (noBeneficiary),
PRIMARY KEY (noKlien),
FOREIGN KEY (noKlien) REFERENCES Klien (noKlien) ON UPDATE CASCADE ON DELETE NO ACTION,
FOREIGN KEY (noBeneficiary) REFERENCES Klien(noKlien) ON UPDATE CASCADE ON DELETE NO ACTION
)
PolisBenefitPremi
Domain nomor polis fixed length character string 7 Domain kode produk fixed length character string 7 Domain kode benefit fixed length character string 7 Domain premi integer
Domain jatuh tempo datetime Domain tanggal klaim datetime
134
Polis Benefit Premi(
noPolis nomor polis NOT NULL,
kdProduk kode produk NOT NULL,
kdBenefit kode benefit NOT NULL,
premi premi NOT NULL,
jatuhTempo jatuh tempo NOT NULL,
tanggalKlaim tanggal klaim NOT NULL,
PRIMARY KEY (noPolis), PRIMARY KEY (KdProduk), PRIMARY KEY (KdBenefit),
FOREIGN KEY (noPolis) REFERENCES Polis (noPolis) ON UPDATE CASCADE ON DELETE NO ACTION,
FOREIGN KEY (KdProduk) REFERENCES ProdukBenefit(KdProduk) ON UPDATE CASCADE ON DELETE NO ACTION,
FOREIGN KEY (KdBenefit) REFERENCES ProdukBenefit (KdBenefit) ON UPDATE CASCADE ON DELETE NO ACTION
)
Produk
Domain kode produk fixed length character string 7 Domain nama produk variable length character string 30 Domain medical status variable length character string, 10
Produk (
135
namaProduk kode produk NOT NULL,
medicalStatus medical status NOT NULL, PRIMARY KEY ( kdProduk )
)
Benefit
Domain kode benefit fixed length character string, 7 Domain nama benefit variable length character string, 20
Benefit (
kdBenefit kode benefit NOT NULL namaBenefit nama benefit NOT NULL PRIMARY KEY (KdBenefit)
)
Cara Bayar
Domain kode cara bayar fixed length character string, 7 Domain jenis cara bayar variable length character string, 20
Cara Bayar (
kdCaraBayar kode cara bayar NOT NULL jenisCaraBayar jenis cara bayar NOT NULL PRIMARY KEY ( kdCaraBayar )
136
Valuta
Domain kode valuta fixed length character string, 7 Domain nama valuta variable length character string, 20
Valuta (
kdValuta kode valuta NOT NULL namaValuta nama valuta NOT NULL PRIMARY KEY ( kdValuta )
)
Identitas
Domain kode Jenis Identitas fixed length character string, 7 Domain jenis Identitas variable length character string, 20
Identitas (
kdJenisIdentitas kode jenis identitas NOT NULL, jenisIdentitas jenis identitas NOT NULL, PRIMARY KEY ( kdJenisIdentitas )
)
Agama
Domain kode agama fixed length character string, 7
137
Agama (
KdAgama kode agama NOT NULL Agama agama NOT NULL PRIMARY KEY ( kdAgama )
)
Tabel 4.7 Tabel Rancangan Dasar Relasi
4.1.3.1.3 Rancangan Data Turunan
Langkah ini bertujuan untuk memutuskan bagaimana merepresentasikan setiap data turunan yang terdapat pada model data logikal global ke dalam DBMS tujuan.
Namun pada ER diagram yang telah dibuat tidak terdapat data turunan.
4.1.3.2 Representasi Fisikal
langkah ini bertujuan untuk mengoptimalkan data yang digunakan untuk memasukan basis relasi dan index yang dibutuhkan untuk mendapatkan tampilan yang sesuai dengan kebutuhan.
Adapun dalam langkah ini terbagi menjadi 4 ( empat ) antara lain: 4.1.3.2.1 Analisa transaksi
Analisa transaksi bertujuan untuk memahami fungsionalitas dari transaksi yang akan berjalan pada
138 basisdata dan untuk menganalisa transaksi yang penting. Tabel 4.4 menunjukan hasil analisa terhadap bebarapa contoh transaksi yang dapat terjadi di dalam basisdata, serta menunjukan tabel – tabel mana saja yang terlibat pada saat transaksi di laksanakan. Adapun transaksi-transaksi yang dapat terjadi :
a. Agen Mengupdate klien
b. Klien mendatangi kantor asuransi untuk melakukan pengisian formulir polis
c. Kantor mengupdate polis d. Polis insert ProdukBenefit
e. ProdukBenefit mengupdate PolisBenefitPremi f. Polis mengupdate PolisBenefitPremi
g. Polis mengupdate HistorisPremi h. Insert Beneficiary untuk Polis i. Update Klien untuk Beneficiary
j. Penagih mengambil surat tagihan untuk klien di kantor
k. Produk dapat meng-update benefit yang ada sesuai kebutuhan pada tabel ProdukBenefit
l. Benefit diinsert pada ProdukBenefit
m. Polis menginsert cara bayar yang telah dipilih oleh Klien
139 o. Agama diinsert ke dalam tabel Klien
p. Valuta diinsert dalam tabel Polis
q. Data penagih ditulis pada polis sebagai bukti telah ditagih asuransinya
r. Kantor dapat mengupdate agen dalam menawarkan polis
s. Data agen ditulis pada polis sebagai bukti penawaran produk asuransi
140 ( a ) ( b ) ( c ) ( d ) Transaksi / relasi R I U D R I U D R I U D R I U D Klien X X Polis X X Kantor X ProdukBenefit X Agen X X Penagih HistorisPremi X BenefitPolisPremi X Beneficiary Agama X Identitas X CaraBayar X Valuta X Produk X X Benefit X X
141 ( e ) (f ) ( g ) ( h ) Transaksi / relasi R I U D R I U D R I U D R I U D Klien X Polis X X Kantor ProdukBenefit Agen Penagih HistorisPremi X X BenefitPolisPremi X X Beneficiary X Agama Identitas CaraBayar Valuta Produk X Benefit X
142 ( i ) ( j ) ( k ) ( l ) Transaksi / relasi R I U D R I U D R I U D R I U D Klien X X Polis X X Kantor X ProdukBenefit X X Agen Penagih X HistorisPremi X BenefitPolisPremi Beneficiary Agama Identitas CaraBayar Valuta Produk X Benefit X X
143 ( m ) ( n) ( o ) ( p ) Transaksi / relasi R I U D R I U D R I U D R I U D Klien X X X Polis X Kantor ProdukBenefit Agen Penagih HistorisPremi BenefitPolisPremi Beneficiary Agama X Identitas X CaraBayar X Valuta X Produk Benefit
144 ( q ) ( r ) ( s ) Transaksi / relasi R I U D R I U D R I U D Klien Polis X X X Kantor X ProdukBenefit Agen X X Penagih X HistorisPremi BenefitPolisPremi Beneficiary Agama Identitas CaraBayar Valuta Produk X Benefit
Keterangan : R= read, I=insert, U= update, D=delete Tabel 4.8 Tabel Analisa Transaksi
145 4.1.3.2.2 Pemilihan organisasi file
Tujuan dari pemilihan data organisasi adalah untuk menentukan sebuah data organisasi yang baik untuk setiap basis relasi. Dengan menggunakan SQL Server 2000 yang mempunyai dua bentuk organisasi file indexes, yakni clustered dan non-clustered.
o Clustered : indeks clustered mengorganisir baris – baris pada tabel ke dalam urutan tertentu.
o Non-clustered : indeks non-clustered memiliki struktur yang terpisah dari tabel. Urutan fisik dari baris tabel tidak mengikuti urutan dari data indeks.
4.1.3.2.3 Pemilihan Index
Penggunaan indeks dilakukan dengan mempertimbangkan impilikasinya terhadap peningkatan performasi sistem. Namun biasanya, entiti / tabel akan secara otomatis di-indeks pada primary
key-nya, atau juga berdasarkan atribut lain sesuai
dengan kebutuhan.
Entiti Indeks
Klien noKlien Polis noPolis
146 Entiti Indeks ProdukBenefit kdProduk kdBenefit Agen kdAgen namaAgen Penagih kdPenagih namaPenagih Kantor kdKantor namaKantor HistorisPremi noPolis tanggalBooked Beneficiary noBeneficiary noKlien PolisBenefitPremi noPolis kdProduk kdBenefit Produk kdProduk namaProduk Benefit kdBenefit CaraBayar kdCaraBayar Valuta kdValuta Identitas kdJenisIdentitas jenisIdentitas Agama kdAgama
147 4.1.3.2.4 Estimasi Disk Space
Berikut ini adalah perkiraan kebutuhan disk space yang dibutuhkan:
1. Tabel Klien
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
noKlien No klien Char 7
namaKlien Nama klien Varchar 20
kdJenisIdentitas Kode Jenis
identitas
Varchar 7
noIdentitas Nomor Identitas Varchar 25
jenisKelamin Jenis kelamin Varchar 10
statusPernikahan Status pernikahan
Varchar 12
tempatLahir Tempat lahir Varchar 20
tanggalLahir Tanggal lahir Small Datetime 4
kdAgama Kode Agama char 7
Pekerjaan Pekerjaan Varchar 20
alamatTetap Alamat tetap Varchar 50
Klien
alamatTagih Alamat tagih Varchar 50
JUMLAH 232
Kapasitas Tabel Klien = 232 bytes
Diperkirakan dalam satu hari terjadi 100 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 232 x 100 x 365 = 8.468.000 bytes = 8269,53 Kbytes
148 2. Tabel Polis
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
noPolis No polis Char 7
kdAgen Kode Agen Char 7
kdPenagih Kode penagih Char 7
kdCaraBayar Kode cara
bayar
Char 7
kdValuta Kode valuta Char 7
noPemegangPolis No pemegang Polis Char 7 noPembayarPremi No Pembayar Premi Char 7
noSPAJ No SPAJ Char 7
tanggalSPAJ Tanggal SPAJ Datetime 8
usiaMasuk Usia masuk Integer 4
tanggalMulai Tanggal mulai Datetime 8
lamaAsuransi Lama Asuransi Integer 4
tanggalEkspirasi Tanggal ekspirasi Datetime 8 lamaPembayaranPremi Lama pembayaran Premi integer 4
akhirBayarPremi Akhir bayar
premi
Datetime 8 Polis
149
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
jumlahUangAsuransi Jumlah uang
asuransi
Integer 4
premiStandar Premi standar Integer 4
Premi5TahunPertama Premi 5 tahun
pertama
Integer 4
premiSetelah5Tahun Premi setelah 5
tahun
Int 4
Resiko Resiko Integer 4
noBp3 No bp3 Char 7
tanggalBp3 Tanggal bp3 Datetime 8
pembayaranTerakhir Pembayaran terkahir
Datetime 8
statusPolis Status polis Varchar 10
statusKlaim Status klaim Varchar 20
JUMLAH 181
Kapasitas Tabel Polis = 181 bytes
Diperkirakan dalam satu hari terjadi 4 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 181 x 4 x 365 = 264260 bytes = 258,07 Kbytes
150 3. Tabel ProdukBenefit
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdProduk Kode produk Char 7
kdBenefit Kode benefit Char 7
ProdukBenefit
nilaiBenefit Nilai benefit Float 8
JUMLAH 22
Kapasitas Tabel Benefit = 22 bytes
Diperkirakan dalam satu tahun terjadi 20 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 22 x 20 = 440 bytes = 0,42 Kbytes
Tabel 4.12 Tabel Estimasi Disc Space pada Tabel ProdukBenefit
4. Tabel Agen
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdAgen Kode agen Char 7
namaAgen Nama agen Varchar 20
kdKantor Kode kantor Char 7
Agen
alamatAgen Alamat agen Varchar 50
JUMLAH 84
Kapasitas Tabel Agen = 84 bytes
Diperkirakan dalam satu bulan terjadi 10 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 84 x 10 x 12 = 10080 bytes = 9,8 Kbytes
151 5. Tabel Penagih
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdPenagih Kode penagih Char 7
namaPenagih Nama penagih Varchar 20
kdKantor Kode kantor Char 7
Penagih
alamatPenagih Alamat penagih Varchar 50
JUMLAH 84
Kapasitas Tabel Penagih = 84 bytes
Diperkirakan dalam satu bulan terjadi 10 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 84 x 10 x 12 = 10080 bytes = 9,8 Kbytes
Tabel 4.14 Tabel Estimasi Disc Space pada Tabel Penagih
6. Tabel Kantor
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdKantor Kode kantor Char 7
namaKantor Nama kantor Varchar 50
alamatKantor Alamat kantor Varchar 50
Kota Kota Varchar 50
noTelp No Telp Varchar 15
noFax No Fax Varchar 15
emailKantor Email kantor Varchar 50
Kantor
statusKantor Status kantor Varchar 25
JUMLAH 262
Kapasitas Tabel Kantor = 262 bytes
Diperkirakan dalam satu tahun terjadi 1 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 262 x 1 = 262 bytes = 0,26 Kbytes
152 7. Tabel HistorisPremi
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
noPolis No polis Char 7
tanggalBooked Tanggal booked Datetime 8
tanggalBayar Tanggal bayar Datetime 8
Premi Premi Integer 4
HistorisPremi
Kuitansi Kuitansi Char 3
JUMLAH 30
Kapasitas Tabel HistorisPremi = 30 bytes
Diperkirakan dalam satu bulan terjadi 50000 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 30 x 50000 x 12 = 18.000.000 bytes = 17.578,13 Kbytes
Tabel 4.16 Tabel Estimasi Disc Space pada Tabel HistorisPremi
8. Tabel Beneficiary
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
noBeneficiary No beneficiary Char 7
Hubungan Hubungan Varchar 10
Beneficiary
noKlien No klien Char 7
JUMLAH 24
Kapasitas Tabel Beneficiary = 24 bytes
Diperkirakan dalam satu hari terjadi 100 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 24 x 100 x 365 = 1.241.000 bytes = 1.211,91 Kbytes
153 9. Tabel PolisBenefitPremi
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
noPolis No polis Char 7
kdProduk Kode produk Char 7
kdBenefit Kode benefit Char 7
Premi Premi Integer 4
jatuhTempo Jatuh tempo Datetime 8
PolisBenefitPremi
tanggalKlaim Tanggal klaim Datetime 8
JUMLAH 41
Kapasitas Tabel PolisBenefitPremi = 41 bytes Diperkirakan dalam satu hari terjadi 50 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 41 x 50 x 365 = 748.250 bytes = 730,71 Kbytes
Tabel 4.18 Tabel Estimasi Disc Space pada Tabel PolisBenefitPremi
10. Tabel Produk
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdProduk Kode produk Char 7
namaProduk Nama produk Varchar 30
Produk
medicalStatus Medical status Varchar 10
JUMLAH 47
Kapasitas Tabel Produk = 47 bytes
Diperkirakan dalam satu tahun terjadi 2 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 47 x 2 = 94 bytes = 0,09 Kbytes
154 11. Tabel CaraBayar
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdCaraBayar Kode cara bayar Char 7
CaraBayar
jenisCaraBayar Jenis cara bayar Varchar 20
JUMLAH 27
Kapasitas Tabel CaraBayar = 27 bytes
Diperkirakan dalam satu tahun terjadi 1 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 27 x 1 = 27 bytes = 0,026 Kbytes
Tabel 4.20 Tabel Estimasi Disc Space pada Tabel CaraBayar
12. Tabel Valuta
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdValuta Kode valuta Char 7
Valuta
namaValuta Nama valuta Varchar 20
JUMLAH 27
Kapasitas Tabel Valuta = 27 bytes
Diperkirakan dalam satu tahun terjadi 1 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 27 x 1 = 27 bytes = 0,026 Kbytes
155 13. Tabel Identitas
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdJenisIdentitas Kode jenis
identitas
Char 7 Identitas
jenisIdentitas Jenis identitas Varchar 20
JUMLAH 27
Kapasitas Tabel Identitas = 27 bytes
Diperkirakan dalam satu tahun terjadi 1 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 27 x 1 = 27 bytes = 0,026 Kbytes
Tabel 4.22 Tabel Estimasi Disc Space pada Tabel Identitas
14. Tabel Agama
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdAgama Kode agama Char 7
Agama
Agama Agama Varchar 20
JUMLAH 27
Kapasitas Tabel Agama = 27 bytes
Diperkirakan dalam satu tahun terjadi 1 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 27 x 1 = 27 bytes = 0,026 Kbytes
156 15. Tabel Benefit
Tabel / Entiti Atribut Deskripsi Tipe Data Ukuran (Byte)
kdBenefit Kode benefit Char 7
Benefit
namaBenefit Nama benefit Varchar 100
JUMLAH 107
Kapasitas Tabel Klien = 107 bytes
Diperkirakan dalam satu tahun terjadi 10 transaksi
Dalam 1 tahun pertumbuhan tabel adalah 107 x 10 = 1070 bytes = 1,04 Kbytes
Tabel 4.24 Tabel Estimasi Disc Space pada Tabel Benefit
Berdasarkan estimasi disc space yang telah dihitung dari tiap-tiap tabel maka dapat ditentukan jumlah dari seluruh estimasi disc space per tahunnya.
Nama Tabel Estimasi disc space dalam satu tahun
Estimasi disc space dalam satu tahun (dengan 50%
safety factor)
Klien 8269,53 Kbytes 12404,295 Kbytes
Polis 258,07 Kbytes 387,105 Kbytes
Kantor 0,26 Kbytes 0,39 Kbytes
ProdukBenefit 0,42 Kbytes 0,63 Kbytes
Agen 9,8 Kbytes 14,7 Kbytes
Penagih 9,8 Kbytes 14,7 Kbytes
HistorisPremi 17.578,13 Kbytes 26367,195 Kbytes
PolisBenefitPremi 730,71 Kbytes 1096,065 Kbytes
157 Nama Tabel Estimasi disc space dalam
satu tahun
Estimasi disc space dalam satu tahun (dengan 50%
safety factor)
Agama 0,026 Kbytes 0,039 Kbytes
Identitas 0,026 Kbytes 0,039 Kbytes
CaraBayar 0,026 Kbytes 0,039 Kbytes
Valuta 0,026 Kbytes 0,039 Kbytes
Produk 0,09 Kbytes 0,135 Kbytes
Benefit 1,04 Kbytes 1,56 Kbytes
Total 28069,864 KBytes 42104,796 KBytes
Total estimasi disc space yang dibutuhkan dalam satu tahun (dengan mempertimbangkan 50 % safety factor) adalah 42104,796 Kbytes atau 41,12 Mbyte Total estimasi disc space yang dibutuhkan dalam lima tahun mendatang (dengan asumsi pertumbuhan jumlah data per tahun adalah 10%) adalah sebesar :
Æ Tahun Pertama = 42104,796 Kbytes atau 41,12 Mbytes Æ Tahun kedua = 46315,2756 Kbytes atau 45,23 Mbytes Æ Tahun Ketiga = 50946,80316 Kbytes atau 49,75 Mbytes Æ Tahun keempat = 56041,48348 Kbytes atau 54,73 Mbytes Æ Tahun Kelima = 61645,63183 Kbytes atau 60,20 Mbytes
Tabel 4.25 Tabel Rekapitulasi Seluruh Estimasi 4.1.3.3 Keamanan
Keamanan yang dimaksud adalah untuk membatasi hak akses kepada pemakai yang bertujuan untuk menjaga
158 keamanan data / informasi yanga ada pada perusahaan. Adapun langkah-langkah yang dapat dilakukan :
4.1.3.3.1 Merancang mekanisme keamanan
Mekanisme keamanan dirancang guna memastikan hanya pengguna yang memiliki otoritas yang berhak mengakses tabel – tabel pada basisdata. Perancangan mekanisme keamanan DBMS, yakni dengan membuat user – user yang akan mengakses basisdata serta memberikan hak tertentu sesuai dengan peran masing – masing user, melalui pernyataan SQL sebagai berikut :
GRANT SELECT ON Produk TO User
GRANT SELECT ON Benefit TO User
GRANT SELECT ON ProdukBenefit TO User
GRANT SELECT ON Polis TO User
GRANT SELECT ON HistorisPremi TO User
GRANT SELECT ON Klien TO User
GRANT SELECT ON Penagih TO User
GRANT SELECT ON PolisBenefitPremi TO User
159 GRANT SELECT ON Valuta TO User
GRANT SELECT ON CaraBayar TO User
GRANT SELECT ON Beneficiary TO User
GRANT SELECT ON Identitas TO User
4.2 Perancangan Aplikasi
Perancangan aplikasi dilakukan dengan meliputi perancangan struktur menu,
State Transition Diagram ( STD ), serta rencangan layar program aplikasi
sebagai sarana interaksi dengan pengguna.Perancangan Aplikasi terdiri dari 6 Out(enam) tahap perancangan yaitu :
1. Perancangan Struktur Program 2. State Transition Diagram 3. Parancangan Input / Output
3.1 Perancangan Input 3.2 Rancangan output 4. Spesifikasi Proses 5. Implementasi
Adapun dalam langkah ini terbagi menjadi 6 ( enam ) antara lain : 5.1 Spesifikasi Perangkat Keras
5.2 Spesifikasi Perangkat Lunak 5.3 Jadwal Implementasi
160 5.4 Kebutuhan Personil ( Brainware )
5.5 Petunjuk Pemakaian Sistem 5.6 Evaluasi
4.2.1 Perancangan Struktur Program
Gambar berikut merupakan perancangan dari struktur program yang akan dibuat untuk user dan admin.
161
Gambar 4.6 Perancangan Struktur Menu Program Admin
4.2.2 State Transition Diagram
Gambar 4.7 sampai dengan Gambar 4.13 mengilustrasikan transisi state ( keadaan ) dari program aplikasi yang akan dibuat untuk user.
162
163
Gambar 4.8 Layar Tentang PT Asuransi Jiwasraya
164
Gambar 4.10 Layar Pelanggan
Gambar 4.11 Layar Login
Gambar 4.12 Layar Direksi
165
Gambar 4.14 sampai dengan Gambar 4.20 mengilustrasikan transisi state ( keadaan ) dari program aplikasi yang akan dibuat untuk admin.
166
167
168
169
170 Halaman Web Admin
Gambar 4.21 Rancangan Halaman Admin Klien
Gambar 4.22 Rancangan Halaman Klien
Selamat Datang Admin PT.Asuransi Jiwasraya
Nama Perusahaan Logo Perusahaan
Klien Polis Produk Karyawan Kantor
Search
Logout
Data Klien
Login Baru Hapus Login Data Klien Baru Update Data Klien Hapus Data Klien Beneficiary Klien Baru Hapus Beneficiary Klien
go Banner Perusahaan
Site Map Contact Us Best Viewed with Mozilla Firefox 1.5.0.6 above ©2006 PT.Asuransi Jiwasraya
Selamat Datang Admin PT.Asuransi Jiwasraya
Nama Perusahaan Logo Perusahaan
Klien Polis Produk Karyawan Kantor
Search
Logout
go Banner Perusahaan
171 • Login Baru
Gambar 4.23 Rancangan Halaman Login Baru
Selamat Datang Admin PT.Asuransi Jiwasraya New Login User ID : Password : Confirm Password : Nomor Klien : Status :
Nama Perusahaan Logo Perusahaan
Klien Polis Produk Karyawan Kantor
Search
Logout
Data Klien
Login Baru Hapus Login Data Klien Baru Update Data Klien Hapus Data Klien Beneficiary Klien Baru Hapus Beneficiary Klien
go Banner Perusahaan
Site Map Contact Us Best Viewed with Mozilla Firefox 1.5.0.6 above ©2006 PT.Asuransi Jiwasraya
172 • Hapus Login
Gambar 4.24 Rancangan Halaman Hapus Login
Selamat Datang Admin PT.Asuransi Jiwasraya Delete Login
No Klien :
Nama Perusahaan Logo Perusahaan
Klien Polis Produk Karyawan Kantor
Search
Logout
Data Klien
Login Baru Hapus Login Data Klien Baru Update Data Klien Hapus Data Klien Beneficiary Klien Baru Hapus Beneficiary Klien
go Banner Perusahaan
Site Map Contact Us Best Viewed with Mozilla Firefox 1.5.0.6 above ©2006 PT.Asuransi Jiwasraya