past, current, and future business conditions. Of course, you can still write basic SELECT statements (i.e., non-temporal queries) against a table with a business time period, and DB2 processing of such queries will remain unchanged. We'll explore a few examples so you can see how easy it is to write temporal queries involving business time. But first, we'll start with the most basic scenario: a situation where you don't need to consider any temporal conditions. Imagine that your POLICY table contains the information shown in Table 15 . (This is the same data shown in Table 12 , immediately after we created the POLICY table and inserted four rows.) To determine the total number of insurance records you have for Policy 1111, you could write the following query: SELECT COUNT(*) FROM policy WHERE id = 1111; Since this query contains no temporal predicates, DB2 returns a value of 2. What if you want to consider various temporal conditions for these insurance policies? You simply include one of three supported period specifications in your query's FROM clause, right after the table name: FOR BUSINESS_TIME AS OF ... FOR BUSINESS_TIME FROM ... TO ... FOR BUSINESS_TIME BETWEEN ... AND ... Let's step through an example. To obtain information about the coverage in effect for Policy 1111 on 1 Dec 2010, you could write the following query: Temporal queries against tables with business time are internally rewritten to a query with appropriate WHERE clause predicates on the appropriate date or timestamp columns defined