Mô hình dữ liệu bảo hiểm nhân thọ

Bảo hiểm nhân thọ là thứ mà tất cả chúng ta hy vọng sẽ không cần đến, nhưng như chúng ta biết, cuộc sống là không thể đoán trước. Trong bài viết này, chúng tôi sẽ tập trung vào việc xây dựng mô hình dữ liệu mà công ty bảo hiểm nhân thọ có thể sử dụng để lưu trữ thông tin của mình.

Bảo hiểm nhân thọ như một khái niệm

Trước khi bắt đầu thảo luận về mô hình dữ liệu thực tế cho một công ty bảo hiểm nhân thọ, chúng tôi sẽ nhắc nhở bản thân một cách ngắn gọn về bảo hiểm là gì và cách hoạt động của nó để chúng tôi có ý tưởng tốt hơn về những gì chúng tôi đang làm việc.

Bảo hiểm là một khái niệm khá cũ đã có từ trước cả thời Trung cổ, khi nhiều bang hội đưa ra các chính sách để bảo vệ thành viên của họ trong những tình huống bất ngờ. Ngay cả nhà thiên văn học, nhà toán học, nhà khoa học và nhà phát minh nổi tiếng Edmund Halley cũng tham gia vào lĩnh vực bảo hiểm, nghiên cứu về số liệu thống kê và tỷ lệ tử vong đã hình thành nên xương sống của các mô hình bảo hiểm hiện đại.

Tại sao bạn phải trả tiền bảo hiểm? Ý tưởng khá đơn giản - bạn trả một số tiền nhất định (phí bảo hiểm) để đổi lấy sự đảm bảo của công ty bảo hiểm rằng bạn hoặc gia đình bạn sẽ được bồi thường tài chính nếu điều gì đó bất ngờ xảy ra với bạn hoặc tài sản của bạn. Trong trường hợp hợp đồng bảo hiểm nhân thọ, bạn chỉ định một người thụ hưởng sẽ nhận được một khoản tiền (quyền lợi) trong trường hợp bạn qua đời. Ý tưởng là số tiền này sẽ giúp họ phục hồi sau khi mất mát, đặc biệt nếu cái chết của bạn gây ra bất kỳ vấn đề tài chính nào.

Tất nhiên, các công ty bảo hiểm thường trả lợi ích ít hơn nhiều so với số tiền họ kiếm được từ phí bảo hiểm và từ việc đầu tư tiền của bạn vào thị trường chứng khoán. Nếu không, họ sẽ phá sản và toàn bộ hệ thống sẽ sụp đổ!

Đó là khá nhiều ý chính của nó. Bây giờ chúng ta đã giải quyết được vấn đề đó, hãy tiếp tục và xem xét mô hình dữ liệu cho một công ty bảo hiểm nhân thọ điển hình.

Mô hình dữ liệu:Tổng quan

Mô hình dữ liệu mà chúng tôi sẽ làm việc bao gồm năm lĩnh vực chủ đề:

Nhân viên
Sản phẩm
Khách hàng
Phiếu mua hàng
Thanh toán

Chúng tôi sẽ trình bày chi tiết hơn từng phần này, theo thứ tự được liệt kê ở trên.

Đối tượng # 1:Nhân viên

Khu vực này không nhất thiết phải cụ thể cho mô hình dữ liệu này nhưng vẫn rất quan trọng vì các bảng chứa ở đây sẽ được tham chiếu bởi các lĩnh vực chủ đề khác. Đối với mục đích của mô hình dữ liệu công ty bảo hiểm của chúng tôi, tất nhiên chúng tôi sẽ cần biết ai đã thực hiện hành động nào (ví dụ:ai đã đại diện cho công ty của chúng tôi khi làm việc với khách hàng / khách hàng, ai đã ký hợp đồng, v.v.).

Danh sách tất cả nhân viên của công ty được lưu trữ trong employee bàn. Đối với mỗi nhân viên, chúng tôi sẽ lưu trữ các thông tin sau:

code - một khóa duy nhất xác định một nhân viên. Vì mã sẽ được sử dụng làm thuộc tính trong các bảng khác nên nó sẽ đóng vai trò là khóa thay thế trong bảng này.
first_name và last_name - họ và tên của nhân viên tương ứng.
birth_date - ngày sinh của nhân viên.

Tất nhiên, chúng tôi chắc chắn có thể bao gồm nhiều thuộc tính khác liên quan đến nhân viên trong bảng này, nhưng bốn thuộc tính này là quá đủ vào lúc này. Chúng tôi sẽ tuân theo mô hình này trong suốt bài viết và cố gắng giữ mọi thứ đơn giản nhất có thể, nhưng lưu ý rằng bạn chắc chắn có thể mở rộng mô hình dữ liệu này để bao gồm thông tin bổ sung.

Vì nhân viên có thể thay đổi vai trò của họ trong công ty của chúng tôi bất kỳ lúc nào nên chúng tôi sẽ cần một bảng từ điển để thể hiện các vai trò của công ty và một bảng để lưu trữ các giá trị. Danh sách tất cả các vai trò có thể có mà nhân viên có thể đảm nhận tại công ty bảo hiểm nhân thọ của chúng tôi được lưu trữ trong role từ điển. Nó chỉ có một thuộc tính có tên là role_name chứa các giá trị nhận dạng duy nhất.

Chúng tôi sẽ liên hệ các nhân viên và vai trò bằng cách sử dụng has_role bàn. Ngoài các khóa ngoại employee_id và role_id , chúng tôi sẽ lưu trữ hai giá trị:start_date và end_date . Hai giá trị này biểu thị phạm vi mà vai trò công ty này đã hoạt động đối với một nhân viên cụ thể. end_date sẽ chứa giá trị null cho đến khi xác định được ngày kết thúc cho vai trò của nhân viên này. Khóa thay thế cho bảng này là sự kết hợp của employee_id , role_id và start_date . Để tránh trùng lặp cùng một vai trò cho cùng một nhân viên, chúng tôi cần kiểm tra theo chương trình xem có trùng lặp nào không mỗi khi chúng tôi thêm bản ghi mới vào bảng hoặc cập nhật bản ghi hiện có.

Lĩnh vực chủ đề # 2:Sản phẩm

Khu vực môn học này khá nhỏ và chỉ chứa hai bảng. Giá trị từ các bảng này là điều kiện tiên quyết cho các lĩnh vực chủ đề khác của chúng tôi, vì vậy chúng ta sẽ thảo luận ngắn gọn về những giá trị này.

product_category từ điển lưu trữ các danh mục sản phẩm chung nhất mà chúng tôi dự định cung cấp cho khách hàng của mình. Giá trị duy nhất mà chúng tôi sẽ lưu trữ trong bảng này là category_name duy nhất để biểu thị loại bảo hiểm mà chúng tôi cung cấp, có thể là bảo hiểm nhân thọ cá nhân, bảo hiểm nhân thọ gia đình, v.v.

Chúng tôi sẽ phân loại các sản phẩm của mình hơn nữa bằng cách sử dụng product bàn. Bảng này đại diện cho các sản phẩm thực tế mà chúng tôi bán chứ không phải danh mục của chúng. Như bạn có thể tưởng tượng, chúng tôi có thể nhóm các sản phẩm theo thời hạn (ví dụ:10 hoặc 20 năm hoặc thậm chí cả đời). Nếu chúng tôi chọn làm như vậy, chúng tôi có thể sẽ có các sản phẩm có cùng product_category_id nhưng tên và mô tả khác nhau. Đối với mỗi sản phẩm, chúng tôi sẽ lưu trữ các thông tin cơ bản sau:

product_name - tên của sản phẩm này. Nó được sử dụng làm khóa thay thế cho bảng này kết hợp với product_category_id thuộc tính. Không chắc chúng ta sẽ có hai sản phẩm trùng tên thuộc các danh mục khác nhau, nhưng dù sao thì vẫn có khả năng xảy ra.
product_category_id - xác định danh mục mà sản phẩm này thuộc về.
product_description - mô tả bằng văn bản của sản phẩm này.

Đối tượng Khu vực # 3:Khách hàng

Giờ đây, chúng tôi đang tiến gần hơn đến cốt lõi của mô hình dữ liệu của mình, nhưng chúng tôi vẫn chưa hoàn thành. Bảo hiểm nhân thọ là duy nhất vì hợp đồng bảo hiểm có thể được chuyển nhượng cho một thành viên gia đình hoặc người khác, trong khi các hợp đồng bảo hiểm cho các hình thức bảo hiểm khác (chẳng hạn như bảo hiểm sức khỏe hoặc bảo hiểm xe hơi) thuộc về một khách hàng duy nhất và không thể chuyển nhượng. Vì lý do này, chúng tôi sẽ không chỉ cần lưu trữ thông tin về khách hàng mà chính sách thuộc về mà còn thông tin về bất kỳ người nào có liên quan và mối quan hệ của họ với khách hàng.

Chúng ta sẽ bắt đầu với client bàn. Đối với mỗi ứng dụng khách, chúng tôi sẽ lưu trữ mã duy nhất được tạo hoặc chèn theo cách thủ công cho ứng dụng khách đó, cũng như các khóa ngoại tham chiếu đến bảng với dữ liệu cá nhân của họ (person_id ) và bảng chứa phân loại nội bộ của chúng tôi (client_category_id ).

client_category từ điển cho phép chúng tôi phân nhóm khách hàng dựa trên thông tin chi tiết về nhân khẩu học và tài chính của họ. Sau đó, các danh mục khách hàng sẽ được sử dụng để xác định chính sách bảo hiểm mà chúng tôi sẵn sàng cung cấp cho một khách hàng cụ thể. Tại đây, chúng tôi sẽ chỉ lưu trữ danh sách các giá trị duy nhất mà sau đó chúng tôi sẽ chỉ định cho khách hàng.

Vì chúng ta đang nói về bảo hiểm nhân thọ, vì vậy chúng ta sẽ giả định rằng khách hàng là một cá nhân. Tuy nhiên, như chúng tôi đã đề cập trước đây, có thể có những người khác có liên quan đến khách hàng mà chính sách có thể được chuyển cho họ hoặc những người có thể nhận được lợi ích từ chính sách khi khách hàng qua đời. Vì lý do này, chúng tôi đã tạo một person bàn. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ thông tin sau:

code - một giá trị được tạo tự động hoặc được chèn theo cách thủ công được sử dụng để nhận dạng duy nhất người có liên quan.
first_name và last_name - họ và tên của người đó tương ứng.
address , phone , mobile và email - chi tiết liên hệ của người này, tất cả đều chứa các giá trị tùy ý.

Hai bảng còn lại trong chủ đề này là cần thiết để mô tả bản chất của mối quan hệ giữa khách hàng và người khác.

Danh sách tất cả các kiểu quan hệ có thể có được lưu trữ trong client_relation_type từ điển. Giống như các từ điển khác, từ điển này sẽ chứa danh sách các tên riêng mà sau này chúng tôi sẽ sử dụng khi mô tả mối quan hệ giữa một khách hàng cụ thể và một người khác.

Dữ liệu quan hệ thực tế được lưu trữ trong client_related bàn. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ các tham chiếu đến ứng dụng khách (client_id ), người có liên quan (person_id ), bản chất của mối quan hệ đó (client_relation_type_id ), tất cả các chi tiết bổ sung (details ), nếu có và cờ cho biết liệu mối quan hệ hiện đang hoạt động hay không (is_active ). Khóa thay thế trong bảng này được xác định bằng sự kết hợp của client_id , person_id và client_relation_type_id .

Chủ đề Khu vực # 4:Phiếu mua hàng

Lĩnh vực chủ đề này và lĩnh vực tiếp theo là trọng tâm của mô hình dữ liệu này. Họ bao gồm các phiếu mua hàng và các chính sách đã ký, cũng như các khoản thanh toán liên quan đến phiếu mua hàng. Đầu tiên, chúng tôi sẽ mô tả chủ đề Phiếu mua hàng. Nó có vẻ phức tạp vì nó chứa 12 bảng. Tuy nhiên, bốn trong số 12 (has_role , product , client và person ) đã được mô tả trong các lĩnh vực chủ đề trước đó, vì vậy chúng tôi sẽ không lặp lại cuộc thảo luận của chúng tôi ở đây.

offer và signed_offer các bảng có cấu trúc tương tự vì chúng sẽ được sử dụng để lưu trữ dữ liệu rất giống nhau trong mô hình của chúng tôi. Tuy nhiên, trong khi offer chủ yếu sẽ được sử dụng để lưu trữ bất kỳ chính sách nào (và chi tiết của chúng) mà chúng tôi đã cung cấp cho khách hàng của mình, signed_offer bảng sẽ được sử dụng nghiêm ngặt để lưu trữ thông tin về những khách hàng đã thực sự ký hợp đồng với công ty chúng tôi. Chúng ta sẽ bao gồm các bảng này lại với nhau, lưu ý bất kỳ sự khác biệt nào khi chúng xuất hiện. Các thuộc tính trong hai bảng này như sau:

client_id - tham chiếu đến mã nhận dạng duy nhất cho khách hàng đã ký một đề nghị cụ thể.
product_id - tham chiếu đến mã nhận dạng duy nhất của sản phẩm có trong phiếu mua hàng đã ký.
has_role_id - tham chiếu đến id của nhân viên và vai trò của họ tại thời điểm đề nghị được trình bày / ký kết.
date_offered và date_signed - ngày thực tế biểu thị thời điểm ưu đãi này được trình bày cho khách hàng và thời điểm nó được ký kết tương ứng.
offer_id - tham chiếu đến đề nghị trước đó cho khách hàng này. Điều này có thể chứa giá trị null vì khách hàng có thể đã ký một chính sách mà không có bất kỳ đề nghị nào trước đó từ công ty, chẳng hạn như nếu họ tự mình tiếp cận chúng tôi. Thuộc tính này hoàn toàn thuộc về signed_offer bảng.
policy_type_id - tham chiếu đến từ điển loại chính sách biểu thị loại chính sách mà chúng tôi đã cung cấp cho khách hàng hoặc họ đã ký.
payment_amount - số tiền khách hàng phải trả cho chính sách một cách thường xuyên.
terms - tất cả các điều khoản của thỏa thuận, ở định dạng văn bản (XML). Ý tưởng là lưu trữ tất cả các chi tiết quan trọng liên quan đến phần tài chính của chính sách trong thuộc tính này. Ví dụ về văn bản mà chúng tôi có thể lưu trữ là tổng số tiền trong hợp đồng, số lần thanh toán mà khách hàng phải thực hiện, v.v.
details - mọi chi tiết bổ sung, ở định dạng văn bản.
is_active - cờ biểu thị liệu bản ghi có còn hoạt động hay không.
start_date và end_date - biểu thị phạm vi thời gian mà chính sách này đang hoạt động. Nếu chính sách được ký suốt đời thì end_date sẽ chứa giá trị null.

Ngoài ra còn có policy_type từ điển mà chúng tôi đã đề cập ngắn gọn trước đây. Chúng tôi cần sự linh hoạt ở một mức độ nào đó trong cách chúng tôi cung cấp cùng một sản phẩm cho các khách hàng khác nhau, dựa trên các yếu tố như tuổi tác, sức khỏe, tình trạng hôn nhân, rủi ro tín dụng, v.v. Đối với mỗi loại chính sách, chúng tôi sẽ lưu trữ một type_name số nhận dạng, một description văn bản bổ sung , một cờ có tên là hết hạn biểu thị liệu chính sách có thể hết hạn hay không và một cờ khác cho biết liệu phí bảo hiểm của loại chính sách này có cần được thanh toán hàng tháng, hàng quý hay hàng năm hay không. Một số loại chính sách dự kiến là:Có kỳ hạn, Trọn đời, Chung sống, Bảo đảm chung, Trọn đời thay đổi, Trọn đời chung có thể thay đổi và Bảo hiểm nhân thọ sau khi nghỉ hưu.

Tiếp tục, bây giờ chúng ta cần xác định tất cả các trường hợp và tình huống mà một chính sách cụ thể có thể bao gồm. Chúng ta cần liên hệ những trường hợp này với các đề nghị cụ thể và đề nghị đã ký.

Danh sách tất cả các trường hợp có thể xảy ra mà chính sách của chúng tôi đề cập đến được lưu trữ trong case từ điển. Mỗi bản ghi trong bảng này có thể được xác định duy nhất bằng case_name của nó và có thêm một description , nếu cần.

in_offer và in_signed_offer các bảng có cùng cấu trúc vì chúng lưu trữ cùng một dữ liệu. Sự khác biệt duy nhất giữa hai loại này là hộp thứ nhất lưu trữ trong chính sách chỉ được cung cấp cho khách hàng, trong khi hộp thứ hai lưu trữ trong chính sách do khách hàng ký. Đối với mỗi bản ghi trong hai bảng này, chúng tôi sẽ lưu trữ một cặp offer_id duy nhất / signed_offer_id và case_id , phần sau biểu thị trường hợp hoặc sự cố được điều chỉnh bởi chính sách. Tất cả các chi tiết khác sẽ được lưu trữ trong một thuộc tính văn bản, nếu cần.

Như chúng tôi đã đề cập trước đây, các hợp đồng bảo hiểm nhân thọ hầu như không chỉ liên quan đến khách hàng mà còn liên quan đến các thành viên trong gia đình hoặc người thân của họ. Chúng ta cũng cần lưu giữ những mối quan hệ này trong lĩnh vực này. Chúng sẽ được xác định tại thời điểm một chính sách được ký kết, nhưng chúng cũng có thể được thay đổi trong suốt thời gian của chính sách.

Điều đầu tiên chúng ta cần làm là tạo một từ điển chứa tất cả các giá trị khả dĩ có thể được gán cho một quan hệ. Trong mô hình của chúng tôi, đây là offer_relation_type từ điển. Ngoài khóa chính, bảng này chỉ chứa một thuộc tính — relation_type - chỉ có thể chứa các giá trị duy nhất.

Tụi mình gần đến nơi rồi! Bảng cuối cùng trong chủ đề này có tiêu đề offer_related . Nó liên quan đến một đề nghị đã ký cho bất kỳ ai có liên quan đến khách hàng. Do đó, chúng tôi sẽ cần lưu trữ các tham chiếu đến chính sách đã ký (signed_offer_id ) và người có liên quan (person_id ) và cũng chỉ rõ bản chất của mối quan hệ đó (offer_relation_type_id ). Ngoài ra, chúng tôi sẽ cần lưu trữ các chi tiết details liên quan đến bản ghi này và tạo cờ để kiểm tra xem nó có còn hợp lệ trong hệ thống của chúng tôi không.

Chủ đề Khu vực # 5:Thanh toán

Chủ đề cuối cùng trong mô hình của chúng tôi liên quan đến các khoản thanh toán. Ở đây, chúng tôi chỉ giới thiệu ba bảng mới:payment , payout_reason và payout .

Tất cả các khoản thanh toán liên quan đến các chính sách được lưu trữ trong payment bàn. Chúng tôi chỉ bao gồm các thuộc tính quan trọng nhất ở đây:

signed_offer_id - tham chiếu đến mã nhận dạng duy nhất của phiếu mua hàng đã ký (chính sách).
payment_date - ngày thanh toán này được thực hiện.
amount - số tiền thực tế đã được thanh toán.
description - mô tả tùy chọn về khoản thanh toán, ở định dạng văn bản.
person_id - tham chiếu đến số nhận dạng duy nhất của người đã thực hiện thanh toán. Lưu ý rằng khách hàng đã ký ưu đãi không nhất thiết phải là người duy nhất có thể thanh toán.
client_id - tham chiếu đến số nhận dạng duy nhất của khách hàng đã thực hiện thanh toán. Thuộc tính này sẽ chỉ chứa một giá trị nếu chính khách hàng đã thanh toán.

Hai bảng còn lại có lẽ đại diện cho lý do quan trọng nhất tại sao chúng tôi trả tiền cho bảo hiểm nhân thọ — rằng trong trường hợp có điều gì đó xảy ra với chúng tôi, các khoản thanh toán sẽ được thực hiện cho các thành viên gia đình hoặc đối tác kinh doanh / cuộc sống của chúng tôi. Điều này xảy ra như thế nào tất cả phụ thuộc vào tình huống của bạn và các điều khoản của chính sách cụ thể mà bạn đã ký. Chúng tôi sẽ sử dụng hai bảng đơn giản để đề cập đến những trường hợp này.

Đầu tiên là từ điển có tiêu đề payout_reason và có cấu trúc từ điển cổ điển. Ngoài thuộc tính khóa chính, chúng tôi chỉ có một thuộc tính - reason_name - sẽ lưu trữ danh sách các giá trị duy nhất cho biết lý do tại sao khoản thanh toán này được thực hiện.

Bảng cuối cùng trong mô hình là payout bàn. Nó rất giống với payment nhưng những khác biệt quan trọng nhất được ghi nhận dưới đây:

payout_date - ngày thanh toán được thực hiện.
case_id - tham chiếu đến mã nhận dạng duy nhất của trường hợp hoặc sự cố liên quan đã kích hoạt thanh toán. Điều này phải khớp với một trong các id có trong chính sách.
payout_reason_id - tham khảo từ điển mô tả lý do thanh toán chi tiết hơn. Mặc dù trường hợp thanh toán ngắn hơn và chung chung hơn, nhưng lý do thanh toán sẽ cung cấp các chi tiết cụ thể hơn về những gì đã xảy ra.
person_id và client_id - đề cập đến người đó và khách hàng có liên quan đến khoản thanh toán tương ứng.

Tóm tắt

Tuyệt vời! Chúng tôi đã xây dựng thành công mô hình dữ liệu bảo hiểm nhân thọ của mình. Trước khi chúng ta kết thúc cuộc thảo luận của mình, cần lưu ý rằng còn rất nhiều điều có thể được đề cập trong mô hình này. Trong bài viết này, chúng tôi chủ yếu muốn trình bày những kiến thức cơ bản về mô hình để giúp bạn có ý tưởng về diện mạo và chức năng của nó. Dưới đây là một số chi tiết khác mà người ta có thể kết hợp vào mô hình dữ liệu như vậy:

Các nâng cấp chính sách bổ sung không được đề cập trong mô hình hiện tại của chúng tôi (ví dụ:nếu bạn muốn cung cấp hàng năm cho các chính sách hiện có, bạn sẽ không thể thực hiện với cấu trúc này). Chúng tôi nên thêm một vài bảng nữa để lưu trữ tất cả các thay đổi về chính sách đối với phiếu mua hàng đã trình bày / đã ký.
Tất cả các thủ tục giấy tờ được cố ý bỏ qua. Tất nhiên, sẽ có khá nhiều thủ tục giấy tờ liên quan đến một hợp đồng bảo hiểm nhân thọ cụ thể, đặc biệt là đối với quá trình ký kết và thanh toán. Chúng tôi có thể đính kèm các tài liệu mô tả trạng thái khách hàng tại thời điểm chính sách được ký kết và mọi thay đổi trong quá trình thực hiện cũng như bất kỳ tài liệu nào liên quan đến các khoản thanh toán.
Mô hình này không kết hợp cấu trúc cần thiết để tính toán rủi ro chính sách. Chúng tôi phải có tất cả các thông số mà chúng tôi cần kiểm tra và bất kỳ phạm vi nào xác định giá trị của khách hàng ảnh hưởng như thế nào đến phép tính tổng thể. Kết quả của các phép tính này sẽ cần được lưu trữ cho từng phiếu mua hàng và chính sách đã ký.
Trên thực tế, cấu trúc hóa đơn phức tạp hơn nhiều so với những gì chúng tôi đã đề cập trong phần chủ đề thanh toán. Chúng tôi thậm chí không đề cập đến tài khoản tài chính ở bất kỳ đâu trong mô hình của mình.

Rõ ràng, hoạt động kinh doanh bảo hiểm khá phức tạp. Chúng ta chỉ thảo luận về một mô hình dữ liệu cho bảo hiểm nhân thọ trong bài viết này - bạn có thể tưởng tượng mô hình dữ liệu này sẽ phát triển như thế nào nếu chúng ta điều hành một công ty cung cấp nhiều loại hình bảo hiểm khác nhau không? Chắc chắn sẽ mất rất nhiều kế hoạch và suy nghĩ để trình bày một mô hình dữ liệu có tổ chức cho một công ty như vậy.

Nếu bạn có bất kỳ đề xuất hoặc ý tưởng nào để cải thiện mô hình dữ liệu của chúng tôi, vui lòng cho chúng tôi biết trong phần nhận xét bên dưới!