schema mapping - subdivision operations

Part of enumeration refraction might be due to class relation and inheritance relations. These can span also over schematic heterogenity and hierarchies of tables possibly distributed in different places from which they need to be integrated. Some of the databases at the end might be able to intepret the meaning and aggregate over hierarchies but in other instances we need to cut queries and aggregate the result in an intermediate place. The subdivision and aggregation operations as tree mapping we have here.

This is the main point where intermediate tables are being materialized and operations can be optimized. It turns out that in complex scenarios the resulting source queries can get very comples and contain a number of subselects or a series of selects that share a common subset of "where"-clauses. Instead of giving the out to a wrapper we serialize the access and rewrite some parts to use intermediate computations.

In traditional operation modes that would come up not so often but in a generalized scenario we keep on unrolling an original sql query to a larger one as in the heterogenity parts and for the conversion parts we see data being joined on some value that would need to be converted - and an indexed intermediate representation can make that a lot easier. All these expand queries from a few to a multitude of tables being involved.

In here we need to check which data tables are of actual use in a real query and then trying to avoid to take the join over all the tables or filter on the union of tables without preselecting records from the tables involved. In quite some cases we do replace original clauses with function calls that give us the value we need includign those pecularities like default values when bringing up records with a missing field from the original source.

Operations

• intermediate table generation - materialized view
• query sequencing - ordering detection for subqueries and intermediates
• record aggregation and default value generation