Is it correct way having status or Summary columns in parent table or should choose another precedure

The third option is to keep a transaction log of points transactions.

Use the schema from your first option to record the "going rate" for points. Whenever you have a transaction that either gives or takes points away from a user, write a record (or multiple records) into a points transaction log table.

The transaction log table will have a FK to USERS and a date/time to indicate when the transaction took place. It could also have FK's to the items which generated the points, such as FK's to your TRANSACTIONS and REPORT_DETAILS tables, that's up to you.

Most importantly, the transaction log table will have a column for the number of points awarded(+) or spent(-). To get a user's point balance, you run a sum of all transactions for the user up until the current time. The important thing is to keep a record of how many points were given or taken for that user, at that time regardless of what may happen to other users or at other times.

If performance becomes an issue, you can keep the user's current point total on the USERS table, but this should be denormalized data based on the transaction log details. If you do this, then you need to have controls in place to make sure you're managing this redundancy appropriately.

From the comments added to the original question, I gather that the central problem with the legacy design centers around types and subtypes (often called classes and subclasses) of claims. This is a classic problem in relational design, Often, new database designers will have had some formal learning concerning many-to-many relationships, data normalization, and similar topics, but no formal learning regarding classes and subclasses.

The Info tab under the Subtypes tag has a brief summary of the problem. It mentions inheritance and object modeling in passing. I want to expand on this a little. The relational data model, in its original form, has no support for inheritance, although some DBMS products have extended the model with inheritance features.

Fortunately, the problem is well understood, and you can gain valuable insights from people who have studied the problem in depth. I particularly like Martin Fowler's treatment. He bridges the gap between how programmers think and how data architects think.

In your case, it appears from your description as though there are a bunch of claim subtype tables, but there is no generic claim table. I'm going to recommend one particular design for your evaluation. It's called "class table inheritance". And I'm going to also recommend a technique called "Shared Primary Key".

In class table inheritance, there will be one table for the generic data that applies to all claims, no matter which subclass they belong to. This table will have a claim ID, used to point to a row, like the usual table. The other columns in the table will contain the attributes that are common to claims regardless of what class they belong to.

The other tables contain data that pertain to particular classes (types) of claims. The ID column of these subclass tables deserves particular attention. It's not populated in the usual way, by having the DBMS assign a unique number to it. Instead it is an "inherited" copy of the ID column of the Class table. This column is both the primary key of the subclass table and a foreign key that references the appropriate row of the claims table.

When you want to deal with a particular class of claim, just join the claims table with the appropriate subclass table. The irrelevant claims will drop out of the join.

The reason I put "inherited" in quotes is that it requires some programming on your part to cause this inheritance to take place when a new claim is added. You have to add the row to the claim table, then obtain the automatically generated ID, then propagate it to the subclass table, before making the insert into the subclass table.

That's my recommendation, but it's your call.