Model Data Asuransi Jiwa

Asuransi jiwa adalah sesuatu yang kita semua harap tidak kita butuhkan, tetapi seperti yang kita tahu, hidup tidak dapat diprediksi. Dalam artikel ini, kami akan fokus pada perumusan model data yang dapat digunakan oleh perusahaan asuransi jiwa untuk menyimpan informasinya.

Asuransi Jiwa sebagai Konsep

Sebelum kita mulai membahas model data aktual untuk perusahaan asuransi jiwa, kita akan secara singkat mengingatkan diri kita sendiri tentang apa itu asuransi dan bagaimana cara kerjanya sehingga kita memiliki gagasan yang lebih baik tentang apa yang sedang kita kerjakan.

Asuransi adalah konsep lama yang sudah ada bahkan sebelum Abad Pertengahan, ketika banyak serikat menawarkan kebijakan untuk melindungi anggota mereka dalam situasi yang tidak terduga. Bahkan astronom, matematikawan, ilmuwan, dan penemu terkenal Edmund Halley mencoba-coba asuransi, mengerjakan statistik dan tingkat kematian yang membentuk tulang punggung model asuransi modern.

Mengapa Anda harus membayar asuransi? Idenya cukup sederhana – Anda membayar sejumlah tertentu (premi) sebagai ganti jaminan perusahaan asuransi bahwa Anda atau keluarga Anda akan diberi kompensasi finansial jika sesuatu yang tidak terduga terjadi pada Anda atau properti Anda. Dalam kasus polis asuransi jiwa, Anda menunjuk ahli waris yang akan menerima sejumlah uang (manfaat) jika Anda meninggal dunia. Idenya adalah bahwa uang ini akan membantu mereka pulih dari kehilangan mereka, terutama jika kematian Anda menimbulkan masalah keuangan.

Tentu saja, perusahaan asuransi biasanya membayar jauh lebih sedikit manfaat daripada yang mereka peroleh dari premi dan dari menginvestasikan uang Anda, katakanlah, pasar saham. Jika tidak, mereka akan bangkrut, dan seluruh sistem akan berantakan!

Itu cukup banyak intinya. Sekarang setelah kita menyelesaikannya, mari kita lihat model data untuk perusahaan asuransi jiwa pada umumnya.

Model Data:Ikhtisar

Model data yang akan kita kerjakan terdiri dari lima bidang subjek:

Karyawan
Produk
Klien
Penawaran
Pembayaran

Kami akan membahas masing-masing bagian ini secara lebih rinci, dalam urutan yang tercantum di atas.

Area Subjek #1:Karyawan

Area ini belum tentu spesifik untuk model data ini tetapi masih sangat penting karena tabel yang terdapat di sini akan direferensikan oleh area subjek lainnya. Untuk keperluan model data perusahaan asuransi kita, tentu saja kita perlu mengetahui siapa yang melakukan tindakan apa (misalnya, siapa yang mewakili perusahaan kita saat bekerja dengan pelanggan/klien, siapa yang menandatangani polis, dan seterusnya).

Daftar semua karyawan perusahaan disimpan di employee meja. Untuk setiap karyawan, kami akan menyimpan informasi berikut:

code — kunci unik yang mengidentifikasi satu karyawan. Karena kode tersebut akan digunakan sebagai atribut di tabel lain, kode tersebut akan berfungsi sebagai kunci alternatif dalam tabel ini.
first_name dan last_name — nama depan dan belakang karyawan, masing-masing.
birth_date — tanggal lahir karyawan.

Tentu saja, kami tentu saja dapat memasukkan banyak atribut terkait karyawan lainnya dalam tabel ini, tetapi keempat atribut ini sudah lebih dari cukup untuk saat ini. Kami akan mengikuti pola ini di seluruh artikel dan mencoba untuk menjaga hal-hal sesederhana mungkin, tetapi perhatikan bahwa Anda pasti dapat memperluas model data ini untuk menyertakan informasi tambahan.

Karena karyawan dapat mengubah peran mereka di perusahaan kami kapan saja, kami memerlukan tabel kamus untuk mewakili peran perusahaan dan tabel untuk menyimpan nilai. Daftar semua kemungkinan peran yang dapat diambil oleh karyawan di perusahaan asuransi jiwa kami disimpan di role kamus. Hanya memiliki satu atribut bernama role_name yang mengandung nilai pengenal yang unik.

Kami akan menghubungkan karyawan dan peran menggunakan has_role meja. Selain kunci asing employee_id dan role_id , kami akan menyimpan dua nilai:start_date dan end_date . Kedua nilai ini menunjukkan rentang di mana peran perusahaan ini aktif untuk karyawan tertentu. end_date akan berisi nilai null hingga tanggal akhir untuk peran karyawan ini telah ditentukan. Kunci alternatif untuk tabel ini adalah kombinasi dari employee_id , role_id , dan start_date . Untuk menghindari duplikasi peran yang sama untuk karyawan yang sama, kita perlu memeriksa secara terprogram untuk setiap tumpang tindih setiap kali kita menambahkan catatan baru ke tabel atau memperbarui yang sudah ada.

Area Subjek #2:Produk

Area subjek ini cukup kecil dan hanya berisi dua tabel. Nilai dari tabel ini merupakan prasyarat untuk bidang subjek kami yang lain, jadi kami akan membahasnya secara singkat.

product_category kamus menyimpan kategori produk paling umum yang kami rencanakan untuk ditawarkan kepada klien kami. Satu-satunya nilai yang akan kita simpan di tabel ini adalah category_name yang unik untuk menunjukkan jenis asuransi yang kami tawarkan, yang dapat berupa asuransi jiwa pribadi, asuransi jiwa keluarga, dan sebagainya.

Kami akan mengkategorikan produk kami lebih jauh menggunakan product meja. Tabel ini mewakili produk sebenarnya yang kami jual dan bukan kategorinya. Seperti yang dapat Anda bayangkan, kami dapat mengelompokkan produk berdasarkan durasi (misalnya, 10 atau 20 tahun, atau bahkan seumur hidup). Jika kami memilih untuk melakukannya, kemungkinan besar kami akan memiliki produk dengan product_category_id yang sama tetapi nama dan deskripsinya berbeda. Untuk setiap produk, kami akan menyimpan informasi dasar berikut:

product_name - nama produk ini. Ini digunakan sebagai kunci alternatif untuk tabel ini dalam kombinasi dengan product_category_id atribut. Kecil kemungkinannya kami akan memiliki dua produk dengan nama yang sama yang termasuk dalam kategori yang berbeda, tetapi tetap saja ada kemungkinan.
product_category_id — mengidentifikasi kategori tempat produk ini berada.
product_description — deskripsi tekstual produk ini.

Area Subjek #3:Klien

Kami sekarang semakin dekat dengan inti model data kami, tetapi kami belum cukup sampai di sana. Asuransi jiwa bersifat unik karena polis dapat dialihkan kepada anggota keluarga atau orang lain, sedangkan polis untuk bentuk asuransi lain (seperti asuransi kesehatan atau asuransi mobil) dimiliki oleh satu klien dan tidak dapat dialihkan. Untuk alasan ini, kita perlu menyimpan tidak hanya informasi tentang klien yang memiliki kebijakan tersebut, tetapi juga informasi tentang orang terkait dan hubungannya dengan klien.

Kita akan mulai dengan client meja. Untuk setiap klien, kami akan menyimpan kode unik yang dibuat atau disisipkan secara manual untuk klien tersebut, serta kunci asing yang mereferensikan tabel dengan data pribadi mereka (person_id ) dan tabel yang berisi kategorisasi internal kami (client_category_id ).

client_category kamus memungkinkan kami untuk mengelompokkan klien berdasarkan demografi dan detail keuangan mereka. Kategori klien kemudian akan digunakan untuk menentukan polis asuransi yang siap kami tawarkan kepada klien tertentu. Di sini, kami hanya akan menyimpan daftar nilai unik yang kemudian akan kami berikan kepada klien.

Karena kita berbicara tentang asuransi jiwa, maka kita akan berasumsi bahwa klien adalah satu individu. Namun, seperti yang kami sebutkan sebelumnya, mungkin ada orang lain yang terkait dengan klien yang kepadanya polis dapat dialihkan atau yang dapat menerima manfaat polis setelah kematian klien. Untuk alasan ini, kami telah membuat person meja. Untuk setiap record dalam tabel ini, kami akan menyimpan informasi berikut:

code — nilai yang dibuat secara otomatis atau dimasukkan secara manual yang digunakan untuk mengidentifikasi orang terkait secara unik.
first_name dan last_name — masing-masing nama depan dan belakang orang tersebut.
address , phone , mobile dan email — detail kontak untuk orang ini, yang semuanya berisi nilai arbitrer.

Dua tabel yang tersisa di area subjek ini diperlukan untuk menggambarkan sifat hubungan antara klien dan orang lain.

Daftar semua jenis relasi yang mungkin disimpan di client_relation_type kamus. Seperti kamus lainnya, ini akan berisi daftar nama unik yang nantinya akan kita gunakan saat menjelaskan hubungan antara klien tertentu dan orang lain.

Data relasi yang sebenarnya disimpan di client_related meja. Untuk setiap record dalam tabel ini, kami akan menyimpan referensi ke klien (client_id ), orang terkait (person_id ), sifat dari relasi tersebut (client_relation_type_id ), semua detail tambahan (details ), jika ada, dan tanda yang menunjukkan apakah relasi saat ini aktif (is_active ). Kunci alternatif dalam tabel ini ditentukan oleh kombinasi client_id , person_id , dan client_relation_type_id .

Area Subjek #4:Penawaran

Area subjek ini dan yang berikut adalah inti dari model data ini. Mereka mencakup penawaran dan kebijakan yang ditandatangani, serta pembayaran yang terkait dengan penawaran. Pertama, kami akan menjelaskan area subjek Penawaran. Ini mungkin tampak rumit karena berisi 12 tabel. Namun, empat dari 12 ini (has_role , product , client , dan person ) telah dijelaskan di bidang subjek sebelumnya, jadi kami tidak akan mengulangi diskusi kami di sini.

offer dan signed_offer tabel memiliki struktur yang mirip karena mereka akan digunakan untuk menyimpan data yang sangat mirip dalam model kita. Namun, sementara offer terutama akan digunakan untuk menyimpan kebijakan apa pun (dan detailnya) yang telah kami tawarkan kepada klien kami, signed_offer tabel akan digunakan secara ketat untuk menyimpan informasi tentang klien yang benar-benar telah menandatangani kebijakan dengan perusahaan kami. Kami akan membahas tabel ini bersama-sama, dengan memperhatikan perbedaan di mana mereka muncul. Atribut pada kedua tabel tersebut adalah sebagai berikut:

client_id — referensi ke pengidentifikasi unik untuk klien yang menandatangani penawaran tertentu.
product_id — referensi ke pengidentifikasi unik produk yang disertakan dalam penawaran yang ditandatangani.
has_role_id — referensi ke id karyawan dan peran yang mereka layani pada saat penawaran diberikan/ditandatangani.
date_offered dan date_signed — tanggal aktual yang menandakan saat penawaran ini disajikan kepada klien dan saat ditandatangani.
offer_id — referensi ke penawaran sebelumnya untuk klien ini. Ini dapat berisi nilai nol karena klien dapat menandatangani polis tanpa memiliki penawaran sebelumnya dari perusahaan, seperti jika mereka mendekati kami sendiri. Atribut ini benar-benar milik signed_offer meja.
policy_type_id — referensi ke kamus jenis polis yang menunjukkan jenis polis yang kami tawarkan kepada klien atau yang mereka tandatangani.
payment_amount — jumlah yang harus dibayar klien untuk polis secara teratur.
terms — semua ketentuan perjanjian, dalam format tekstual (XML). Idenya adalah untuk menyimpan semua detail penting mengenai bagian keuangan dari polis dalam atribut ini. Contoh teks yang dapat kami simpan adalah jumlah total polis, jumlah pembayaran yang harus dilakukan klien, dan sebagainya.
details — detail tambahan apa pun, dalam format tekstual.
is_active — bendera yang menunjukkan apakah rekaman tersebut masih aktif.
start_date dan end_date — menunjukkan rentang waktu di mana kebijakan ini aktif/aktif. Jika kebijakan ditandatangani seumur hidup, maka tanggal_akhir akan berisi nilai nol.

Ada juga policy_type kamus yang kami sebutkan secara singkat sebelumnya. Kami memerlukan beberapa tingkat fleksibilitas dalam cara kami menawarkan produk yang sama kepada klien yang berbeda, berdasarkan faktor-faktor seperti usia, kesehatan, status perkawinan, risiko kredit, dan sebagainya. Untuk setiap jenis kebijakan, kami akan menyimpan type_name pengenal, description tekstual tambahan , tanda bernama kedaluwarsa yang menandakan apakah polis dapat kedaluwarsa, dan tanda lain yang menunjukkan apakah premi jenis polis ini perlu dibayar bulanan, triwulanan, atau tahunan. Beberapa jenis polis yang diharapkan adalah:Term Life, Whole Life, Universal Life, Guaranteed Universal Life, Variable Life, Variable Universal Life, dan Life Insurance After Retirement.

Selanjutnya, kita sekarang perlu mendefinisikan semua kasus dan situasi yang dapat dicakup oleh kebijakan tertentu. Kami perlu menghubungkan kasus ini dengan penawaran khusus dan penawaran yang ditandatangani.

Daftar semua kemungkinan kasus yang tercakup dalam kebijakan kami disimpan di case kamus. Setiap record dalam tabel ini dapat diidentifikasi secara unik dengan case_name dan memiliki description tambahan , jika diperlukan.

in_offer dan in_signed_offer tabel berbagi struktur yang sama karena mereka menyimpan data yang sama. Satu-satunya perbedaan antara keduanya adalah bahwa yang pertama menyimpan kasing yang tercakup dalam polis yang hanya ditawarkan kepada klien, sedangkan yang kedua menyimpan kasing dalam polis yang ditandatangani oleh klien. Untuk setiap record dalam dua tabel ini, kami akan menyimpan pasangan unik offer_id /signed_offer_id dan case_id , yang terakhir menunjukkan kasus atau insiden yang tercakup dalam polis. Semua detail lainnya akan disimpan dalam atribut tekstual, jika diperlukan.

Seperti yang kami sebutkan sebelumnya, polis asuransi jiwa hampir selalu terkait tidak hanya dengan klien tetapi juga dengan anggota keluarga atau kerabat mereka. Kita perlu menyimpan hubungan ini di area ini juga. Mereka akan ditentukan pada saat kebijakan ditandatangani, tetapi mereka juga dapat diubah selama durasi kebijakan.

Hal pertama yang perlu kita lakukan adalah membuat kamus yang berisi semua kemungkinan nilai yang dapat diberikan ke suatu relasi. Dalam model kami, ini adalah offer_relation_type kamus. Selain dari kunci utama, tabel ini hanya berisi satu atribut—relation_type – yang hanya dapat menyimpan nilai unik.

Kami hampir sampai! Tabel terakhir di bidang subjek ini berjudul offer_related . Ini terkait dengan penawaran yang ditandatangani kepada siapa saja yang terkait dengan klien. Oleh karena itu, kita perlu menyimpan referensi ke kebijakan yang ditandatangani (signed_offer_id ) dan orang terkait (person_id ) dan juga tentukan sifat dari relasi tersebut (offer_relation_type_id ). Selain itu, kita harus menyimpan details terkait dengan catatan ini dan buat tanda untuk memeriksa apakah itu masih valid di sistem kami.

Area Subjek #5:Pembayaran

Area subjek terakhir dalam model kami menyangkut pembayaran. Di sini, kami hanya memperkenalkan tiga tabel baru:payment , payout_reason , dan payment .

Semua pembayaran yang terkait dengan kebijakan disimpan di payment meja. Kami hanya menyertakan atribut yang paling penting di sini:

signed_offer_id — referensi ke pengidentifikasi unik dari penawaran yang ditandatangani (kebijakan).
payment_date — tanggal pembayaran ini dilakukan.
amount — jumlah sebenarnya yang dibayarkan.
description — deskripsi opsional pembayaran, dalam format tekstual.
person_id — referensi ke pengidentifikasi unik orang yang melakukan pembayaran. Perhatikan bahwa klien yang menandatangani penawaran belum tentu satu-satunya orang yang dapat melakukan pembayaran.
client_id — referensi ke pengidentifikasi unik klien yang melakukan pembayaran. Atribut ini akan berisi nilai hanya jika klien sendiri yang melakukan pembayaran.

Dua tabel yang tersisa mungkin mewakili alasan paling penting mengapa kita membayar asuransi jiwa—bahwa jika sesuatu terjadi pada kita, pembayaran akan dilakukan kepada anggota keluarga atau mitra bisnis/jiwa kita. Bagaimana ini terjadi semua tergantung pada situasi Anda dan ketentuan kebijakan khusus yang Anda tandatangani. Kami akan menggunakan dua tabel sederhana untuk membahas kasus ini.

Yang pertama adalah kamus berjudul payout_reason dan menampilkan struktur kamus klasik. Selain atribut kunci utama, kami hanya memiliki satu atribut – reason_name – yang akan menyimpan daftar nilai unik yang menunjukkan mengapa pembayaran ini dilakukan.

Tabel terakhir dalam model adalah payment meja. Ini sangat mirip dengan payment tabel, tetapi perbedaan yang paling penting dicatat di bawah ini:

payment_date — tanggal pembayaran dilakukan.
case_id — referensi ke pengidentifikasi unik dari kasus atau insiden terkait yang memicu pembayaran. Ini harus cocok dengan salah satu ID yang disertakan dalam kebijakan.
payout_reason_id — referensi ke kamus yang menjelaskan alasan pembayaran secara lebih rinci. Meskipun kasus pembayaran lebih pendek dan lebih umum, alasan pembayaran akan menawarkan detail yang lebih spesifik tentang apa yang terjadi.
person_id dan client_id — merujuk orang dan klien yang terkait dengan pembayaran, masing-masing.

Ringkasan

Luar biasa! Kami telah berhasil membangun model data asuransi jiwa kami. Sebelum kita mengakhiri diskusi kita, perlu dicatat bahwa ada lebih banyak lagi yang bisa dibahas dalam model ini. Dalam artikel ini, kami terutama ingin membahas dasar-dasar model untuk memberi Anda gambaran tentang tampilan dan fungsinya. Berikut adalah beberapa detail lebih lanjut yang dapat dimasukkan ke dalam model data seperti itu:

Upgrade kebijakan tambahan tidak tercakup dalam model kami saat ini (misalnya, jika Anda ingin membuat penawaran tahunan untuk kebijakan yang ada, Anda tidak akan dapat melakukannya dengan struktur ini). Kami harus menambahkan beberapa tabel lagi untuk menyimpan semua perubahan kebijakan untuk penawaran yang disajikan/ditandatangani.
Semua dokumen sengaja dihilangkan. Tentu saja, akan ada cukup banyak dokumen yang terkait dengan polis asuransi jiwa tertentu, terutama untuk proses penandatanganan dan pembayaran. Kami dapat melampirkan dokumen yang menjelaskan status klien pada saat polis ditandatangani dan perubahan apa pun yang terjadi, serta dokumen apa pun yang terkait dengan pembayaran.
Model ini tidak memasukkan struktur yang dibutuhkan untuk perhitungan risiko kebijakan. Kami harus memiliki semua parameter yang perlu kami uji dan rentang apa pun yang menentukan bagaimana nilai klien memengaruhi penghitungan keseluruhan. Hasil perhitungan ini perlu disimpan untuk setiap penawaran dan kebijakan yang ditandatangani.
Struktur faktur pada kenyataannya jauh lebih kompleks daripada apa yang kami bahas di area subjek pembayaran. Kami bahkan tidak menyebutkan akun keuangan di mana pun dalam model kami.

Jelas, bisnis asuransi cukup kompleks. Kami hanya membahas model data untuk asuransi jiwa dalam artikel ini — dapatkah Anda bayangkan bagaimana model data ini akan berkembang jika kami menjalankan perusahaan yang menawarkan sejumlah jenis asuransi yang berbeda? Tentu akan membutuhkan banyak perencanaan dan pemikiran untuk menyajikan model data yang terorganisir untuk perusahaan seperti itu.

Jika Anda memiliki saran atau ide untuk meningkatkan model data kami, jangan ragu untuk memberi tahu kami melalui komentar di bawah!