Honestly speaking database design is under physical design phase so cant tell whether my approach is good or not ? thats the reason i posted the question here.
I really think you're over analysing it for that number of records. As far as DBA performance goes nowadays the focus is less on splitting components of tables over physical disks and more about getting everything into RAM. (as compared to when I did the SQL 2000 MCDBA) You will seriously see no performance advantage in vertically splitting data accross disks if you have only a couple thousand records.
i didnt get this , please explain .what i inderstand here is for every claimID from claim table there must be a record in claim_summary table.
If that's the case then yes it's 1:1. My mistake - usually a 'summary' table is a summary of some kind of detail and has less rows and less detail but in your case the summary appears to be additional generated information.
Looking at your original question, are the claim summary calculations based solely on columns in the claims table? Because you can simply use calculated columns in the same table for that. Then you don't need SSIS at all (and I would argue you still don't need it anyway)
I am of the opinion that a simple design is a good design and adding SSIS and filegroups and vertical table partitioning to a table with a few thousand rows is way over the top. But everyone has made good contributions here and some valid reasons have indeed been given to split it.