Another way to solve a loop in the data foundation structure is to create contexts. A context resolves a loop by defining a set of joins that identify one specific path through tables in a loop. It ensures that joins are not included from different paths within the same SQL query.
You use contexts in a schema that contains multiple fact tables that share lookup tables. An example of this situation is the Sale table in the Motors Data Foundation. The Sale table contains rows of data for cars both sold and rented. The Sale_Type column is used as a flag to indicate the type of transaction (S = car sale, R = car rental). Without the restriction, the result set of the query would produce rows where the Sale_Type column is equal to either ‘S’ or ‘R’.
Previously, you defined this restriction to ‘S’, so that any object based on the table, or joins passing through that table, would produce query results covering only car sales. One way to retrieve data concerning rental sales is to create an alias of the SALE table called RENTAL, set the restriction to ‘R,’ and create an alias table of the SALE_MODEL table called RENTAL_MODEL.
Creating the aliases tables, however, creates a loop. The query does not know which table to go through to move from the CLIENT table to the MODEL table, the SALE or the alias RENTAL table.
Any objects derived from tables included in a context are compatible with each other. When a query is made with objects related to separate contexts, more than one
SELECT statement is inferred and run. The results of the queries are then merged in the end user's tool. This method avoids incorrect results that might arise due to a loop or other situations with alternative routes.