Normalising.....how Far Do You Go?

Jan 9, 2008

I am about to start helping someone make a data base and since it is a "start from scratch" I am going to avoid errors that are in my own data base. In both cases our occupations are insurance.

One obviously important part of the data is the recording/description of policy benefits. In my own data base I have all of this in one table which results in null fields in about every record

There are basically four types of policy and they all have some common fields or data which are

Policy Type.... Huge repeater in the record set
Insurance Co...Huge repeater in the record set
Policy Number
Application Date
Commence Date
Benefit Amount
Mode of Payment......Huge repeater in the record set
Payment Amount
Policy Status......Huge repeater in the record set

There would be no null fields in any of the above except for a perid of time following application. Commencement Date can be anywhere from a couple of weeks to several months after the application date but all the other fields have data from about day 1.

There are then fields that only apply to each policy type and also they repeat a great amount throughout the record set.

For example, Income Replacement insurance will have

Waiting Period....98% of the policies will be 2, 4 or 13 weeks

Benefit Period Sickness....virtually all will be Age 65 or Life or 2 years
Benefit Period Accident...Same range as above but period could be different. Could have Sickness for 2 years and Accident to Age 65

Approximately 2/3rds of the records would have null fields for the above.

Life Insurance, Total and Permanent Disability and Trauma Cover also have a couple of fields that only apply to each type of cover.

There are four fields which for the vast majority of records three of the fields will be null.

Issued Standard Y or N. Obviously a huge repeater.

If not a standard isssue (minority of policies) then these fields get entries

Premium Loading. Nearly every record will be null and those with an entry will only have a few different entries eg. 150%, 200% etc

Policy Conditions Altered Y or N

Altered Policy Condtions....Paragraph 27 changed to whatever etc

How far down would you break it. If it is all in one table there are 26 fields. (just counted mine:D)

There are only 5 fields where they apply to every policy type and where the data is not hugely repeated through the record set.

Policy Number
Application Date
Commence Date
Benefit Amount
Payment Amount

View Replies


ADVERTISEMENT

Normalising A Data Base......subform Problems

Mar 29, 2008

I have been helping a friend make a data base that is essentially the same as my own but since it is being made from scratch I have tried to remove the problem areas that exist in my own.

The main problem area with this data base is the size of the main table which is about 240 fields. This limits number of records, speed being one issue with some queries that are run. I have managed to lop this table down in size by a large amount. Much of that being done by moving to different tables the records for prospects, insurance clients and personal or non insurance records. That removes many fields because each category has different description fields.

But I have a problem with the table that now holds prospects for telemarketing. There are about 30 fields that hold data that results from each telemarketing call and instead of that being 30 of 240 fields it is now 30 of about 50 fields so looks like a big deal now:D. Five of those are for the date/time of each call, and the others are the various call results and date/times, days which determine whether the record will be displayed (call backs, appointment made etc). After the call is completed clicking "next record" opens a new record in another table and SetValues the field with the required data from the "main form". So some double handling.

However, if I remove all of this from the "prospect table" I have a display problem and changing the display is not an option as it evolved over a long period to give the best calling results. The various fields are displayed in groups on the main form. It could not be duplicated with the normal subform. Perhaps a subform that was columnar would work. Although I would need to keep a few of the fields in the prospect table as they determine "if and when" are record is in the cold calling list for the day.

I could have two tables and join with query but I don't think there is much point. One reason alone being that for the vast majority of prospects there would be no records in a second table because they have not been called.

My feeling is that leaving the prospect table the way it is would be the best and easiest. But I am open to any suggestions because at this stage there is nothing hanging off the table so am I free to do whatever.

View 14 Replies View Related







Copyrights 2005-15 www.BigResource.com, All rights reserved