A calculation facility that merely computes 123*456 isn't much use. We've got calculators and spreadsheets for that.
But an application that lets you define a calculation like
and has the smarts to evaluate that expression using the current values of store1DailyRevenue and store2DailyRevenue from your transaction database - now that's useful. (Even better if it can trend that expression over time, but we'll demonstrate that elsewhere).
If you're building an application that allows users to define their own calculations, then your users will thank you for allowing them to build on top of their existing data-stores, using names that they are familiar with.
But it's not enough simply to reference external entities - how it's done is also important. There are applications out there that force their users to use a horrendous graphical interface to define calculations. Needless to say, don't go there.
But even text-based representations can be done badly. For example, the following is painful, but not uncommon
In a complex calculation, the logic and the intent gets completely lost with all that tag-delimiting overhead.
And you also want to make sure that the calc engine imposes no limits on how your application resolves those tag into numbers. What constitutes a tagname, where the data comes from (one datasource? several datasources? the current values? the values at midnight?) - that should be entirely up to your application.
One last thought for those who are quite familiar with grabbing named values and building them into applications: What if everything could be a calculation? What if the parsing overhead was so negligible, the configuration so trivial that there was no point distinguishing between a "raw" entity and a "calculated" entity? What might your users create then? What could YOU create?