Well, I don’t believe there is a design pattern which can help you here, but maybe some “tactics”. Honestly, it is hard to give you a good answer with so few bits of information. Here are my thoughts, based on some guessing how your code may look like:

• start by refactoring that (too) big method into smaller methods. Make the structure transparent, introduce variables for intermediate results, decouple independent parts of the calculation, make sure the same calculation does not exist redundantly in two places of your source code. Also, introduce data structures for attributes which belong together

• visualize your data flow (for example, by drawing a data flow diagram). This will help you to understand the dependencies better and probably help you by further refactoring into indenpendent parts or components. It will also help you to understand where you have to change something when a new requirement arises.

• check if you really need a “push model” for your calculations (a change in one attribute triggers a sequence of calculations, you have to update a lot of intermediate variables, perhaps have to deal with unwanted side effects), or if you can switch to a more functional “pull model” (only when a specific value is needed the related calculations are triggered, calculating all the intermediate results from the current state of your input variables). A “pull model” works like an SQL view in a relational DB, a “push model” like an utility table in a relational database which has to be filled with redundant data.

• it may be also a good idea to decouple your program from that “3 different data models” by introducing an intermediate layer which gives your calculation code a view upon the data which is suited for its needs. But with so few information how you calculation may look like, I am unsure if thats the right decision in your case, you have to decide that by yourself.

Well, something that might be helpful for you is doing Refactor:

Refactoring is a disciplined technique for restructuring an existing
body of code, altering its internal structure without changing its
external behavior. Its heart is a series of small behavior preserving
transformations. Each transformation (called a ‘refactoring’) does
little, but a sequence of transformations can produce a significant
restructuring. Since each refactoring is small, it’s less likely to go
wrong. The system is also kept fully working after each small
refactoring, reducing the chances that a system can get seriously
broken during the restructuring.
http://refactoring.com/

There is a book about it.

Anyway. I was in the same situation and I have to do a lot of refactor, like:

Simplifying blocks of if statements in methods doing “Decompose Conditional”

Decompose Conditional You have a complicated conditional (if-then-else) statement. Extract methods from the condition, then part, and else parts.

if (date.before (SUMMER_START) | | date.after( SUMMER_END))
     charge = quantity * _winterRate + _winterServiceCharge; 
else    
     charge = quantity * _summerRate; 

Changed to:

if (notSummer( date))
    charge = winterCharge( quantity);
else
    charge = summerCharge (quantity);

Consolidating conditional expressions in a single method. For example, if I have a bunch of ifs in a method before doing the real job, then I group all those ifs in one single method

Once that you have done some refactor of your code, you realize that is easy move the pices together so at that point I would suggest the Strategy pattern.

In computer programming, the strategy pattern (also known as the
policy pattern) is a software design pattern, whereby an algorithm’s
behaviour can be selected at runtime. http://en.wikipedia.org/wiki/Strategy_pattern

and finally, remove switch statements (if you have them) with some polymorhism.