Your schema is fine, assuming that the values are all numeric (which is reasonable for statistical values).
This structure is called entity-value-attribute (EVA) models. These store each value on a separate line. In general, they are not the best way to store data. However, in this case, you have a flexible number of statistics on a variety of tables. And both might change over time. So, it seems like a reasonable application.
You can probably increase performance of your queries with appropriate indexing. Without seeing the queries, the right approach is speculative.
Question (2) is rather difficult. It is not to hard for your example, but if you want to support hierarchical expressions, it will get complicated (that is, expressions based on other expressions). For your example, you have three basic options:
- You can use triggers to update values. You have to have additional columns or another table specifying the relationships.
- You can use views to retrieve the values, doing the calculation when you fetch the results.
- You can use stored procedures for all changes to the data, and put the logic in the stored procedure.
The second option would be my first approach. The third would then be my preference.