4 回答
This looks like a case for Chain of Responsibility. You would have handlers for each legislature. You pass the application to the most recent handler first. If it is too old, it passes it down to the handler for the previous legislature.
You can use a few patterns. For example using the temporal property pattern you can create on object which contains business rules which are active at a certain point in time. Also, using the specification pattern you can create business rules which are effective based on a certain date. You can associate an effective date range with each policy so that the decision of whether a given policy applies can be made. The book Analysis Patterns contains many patterns that could be applicable in your scenario.
EDIT: I meant to link to the temporal object pattern instead of temporal property. This may shed some light on implementing the database mapping.
If the rules are complex you may need a (business) rules engine. I don't know what implementations exist for your platform, but for Java the typical choice is Drools and its Expert subproject. It defines domain-specific language for defining rules. Note that it might have an interface for non-java users.
Otherwise you may try something like the Strategy pattern - you have a list of strategies with two methods appliesTo(date) and handle(data). You iterate the list and if a strategy is applicable to a date - let it handle the data.
At the architecture level, there are two approaches to solve this problem.
The first is to ETL the data to your Warehouse before the business logic is applied against the data. I prefer this approach.
Sometimes though, it's not possible to do this--i.e., the business logic is applied against the data before it is written to the OLTP (the source used to populate the Data Warehouse) so you have no choice. In this instance, this problem is usually referred to as a rapidly changing dimension problem. (My assumption here is that the data referred to in your question is stored in a Dimension Table rather than a Fact Table).
There is a vast body of commentary on this subject available on the Web. Among these sources, i recommend any of the articles (free) or books (not free) by Ralph Kimball.
The best way to reconcile a rapidly changing dimension is almost certainly fact specific; still, perhaps the most common technique is to c*reate a new dimension table* that stores the data applied against the new business logic. In other words, you would have in your DW schema a separate dimension table for for each business rule.