Subject: eClaims Data Modeling

Question: Hello,
I chance upon your website.
I am gladful with your expertise and your willingness to help.
Doing data modeling was something I did more than 10 yrs back...thus I am not so experience in it.

Hope you can help.

I am currently stuck and is very reluctant to move my Current company eClaims system to a regional one,

revamping the data model with more than 100+ tables in Oracle.

Currently only 2 countries are using the Claim system, we intend to launch it to 7000 staff all over the world.

There are 18 Claims type altogether, some data fields/claim type can do data mapping, some may not.

Claims are like local transport claim, travel expenditure claim, child birth, handphone subsidy, marriage claim,
meal subsidy for Overtime, etc.

The current system has got at least 2 to 3 transaction tables for each Claim type, so there are more than 100+
altogether for this way of duplicating way of modelling.

I find this too messy.

I am tempted to group a few claim types together with similar claim details for design on 1 shared table with
Claim type and code, and claimant ID, Date as keys.

However, while this will reduce the numbers of tables, there are other problems.

If the claims details table grew to big (there is no archiving), the searching on one single claim details table
will be TOO SLOW as TABLE SIZE grows too huge.

Especially for claims such as Transport, handphone subsidy and Meal subsidy.

What is your opinions with a modeling system like eClaims.

With process parameters setting tables, master details table, claim headers table, there are more than 100 tables in all.

Do you think 1 claim type with 1 set of tables is a good data modeling approach like the current system? Or what other
approaches can you help with a kickstart to help link me too in your website? Appreciate for your help.