• Tidak ada hasil yang ditemukan

BAB 4 PERANCANGAN DAN IMPLEMENTASI. terdiri dari 3 (tiga) tahap perancangan yaitu : 1. Perancangan basisdata konseptual

N/A
N/A
Protected

Academic year: 2021

Membagikan "BAB 4 PERANCANGAN DAN IMPLEMENTASI. terdiri dari 3 (tiga) tahap perancangan yaitu : 1. Perancangan basisdata konseptual"

Copied!
170
0
0

Teks penuh

(1)

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:

(2)

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

(3)

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

(4)

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

(5)

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..*

(6)

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

(7)

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

(8)

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

(9)

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

(10)

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

(11)

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

(12)

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

(13)

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

(14)

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

(15)

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 :

(16)

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

(17)

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)

(18)

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

(19)

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

(20)

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)

(21)

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)

(22)

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)

(23)

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

(24)

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 :

(25)

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)

(26)

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,

(27)

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

(28)

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,

(29)

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

(30)

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

(31)

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 –

(32)

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

(33)

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

(34)

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

(35)

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 (

(36)

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,

(37)

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,

(38)

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

(39)

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

(40)

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

(41)

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

(42)

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 (

(43)

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 )

(44)

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

(45)

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

(46)

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

(47)

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

(48)

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

(49)

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

(50)

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

(51)

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

(52)

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

(53)

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

(54)

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

(55)

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

(56)

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

(57)

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

(58)

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

(59)

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

(60)

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

(61)

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

(62)

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

(63)

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

(64)

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

(65)

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

(66)

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

(67)

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

(68)

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.

(69)

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.

(70)

162

(71)

163

Gambar 4.8 Layar Tentang PT Asuransi Jiwasraya

(72)

164

Gambar 4.10 Layar Pelanggan

Gambar 4.11 Layar Login

Gambar 4.12 Layar Direksi

(73)

165

Gambar 4.14 sampai dengan Gambar 4.20 mengilustrasikan transisi state ( keadaan ) dari program aplikasi yang akan dibuat untuk admin.

(74)

166

(75)

167

(76)

168

(77)

169

(78)

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

(79)

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

(80)

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

Gambar

Gambar 4.4 Model logikal terhadap transaksi
Gambar berikut merupakan perancangan dari struktur program yang akan  dibuat untuk user dan admin
Gambar 4.6 Perancangan Struktur Menu Program Admin
Gambar 4.7 Layar Halaman awal User
+7

Referensi

Dokumen terkait

Apalagi mengingat bahwa lokasi perancangan memiliki karakteristik site yang spesifik dan unik sehingga hal ini dijadikan dasar perancangan utama dalam perancangan bangunan

• Kawasan kategori VI sangat unik diantara sistem kategori IUCN, mempunyai wilayah untuk pemanfaatan sumber daya alam secara berkelanjutan sebagai cara untuk mencapai

mengevaluasi program kegiatan kemahasiswaan dan pelayanan kesejahteraan mahasiswa serta merencanakan, melaksanakan, dan mengevaluasi kerjasama dengan instansi

‹ ‹ Kepada Kepada setiap setiap entitas entitas pengguna pengguna diberikan diberikan suatu suatu kode kode unik unik (dengan ( dengan panjang panjang 64 bit 64 bit) ) yang

(3) Materi laporan sebagaimana dimaksud pada ayat (1) meliputi Laporan Kemajuan Pelaksanaan Kegiatan, Laporan Kemajuan Pelaksanaan pekerjaan yang dilakukan oleh penyedia,

Whitelist adalah aturan yang ditetapkan Twitter (pada Twitter API v1) dengan memasukkan alamat mesin ke daftar putih Twitter dan memberikan keringanan dalam hal keterbatasan dalam

yang disitasi Ariffin (2010), VBAC tidak dilakukan pada pasien yang pernah seksio sesarea dua kali berurutan atau lebih, sebab pada kasus tersebut seksio sesarea

MENGECAP GAMBAR BUNGA DENGAN MEDIA BELIMBING Bahan dan alat yang digunakan untuk kegiatan tersebut adalah