[teiid-issues] [JBoss JIRA] (TEIID-2309) Add support for "conformed" tables in Teiid

[Steven Hawkins (JIRA)]

     [ https://issues.jboss.org/browse/TEIID-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins updated TEIID-2309:
----------------------------------

    Fix Version/s: 8.6


Provisionally putting into 8.6.  The optimizer logic is fairly straight-forward - however there is no clarity on how table conformity will be specified by the user.

Possiblities include:
- An extension property on the canonical table indicating the other source names in which it exists
This can be done at design, altered deploys (mixing in ddl alter option statements in the vdb.xml to set the metadata) or runtime (through property updates which would require a custom metadata repository)
A downside is that no metadata will exist in the Teiid system for the table on the other source.  A variation would be akin to setting the materialization target such that a fully qualified list of existing conforming targets could be specified.
Another downside is that you have to be consistent in choosing the canonical table at design time otherwise the confirmed extension property would have to exist on all of the conformed tables or we would have to internally set that.
- A more general design time concept of a conformed table/model (although I'm not entierly sure what that would look like)
- A more general runtime approach based upon the temp table integration (but creating actual tables) to create copies of the reference data on the fly.

                
> Add support for "conformed" tables in Teiid
> -------------------------------------------
>
>                 Key: TEIID-2309
>                 URL: https://issues.jboss.org/browse/TEIID-2309
>             Project: Teiid
>          Issue Type: Feature Request
>          Components: Query Engine
>            Reporter: Debbie Steigner
>             Fix For: 8.6
>
>
> Teiid would support tables from different data sources being marked as "conformed", meaning they are the same (or perhaps a different name).  When optimising a query, it would take the conformity into account and choose the appropriate copy of the table (presumably one in the same database as other tables in the query, if available).  I would not regard it as a problem if Teiid *required* the dimensions to be strictly the same as opposed to permitting subsets, though as with so many areas, it would be up to the user to ensure this was really true: I would not expect the engine to do anything to verify that the tables really were conformed.
> Usecase:
> In Data Warehousing, it is relatively common to have multiple copies of the same dimensions spread over multiple Data Warehouses or Marts, or in the same Data Warehouse when associated with different Fact Tables.  If these copies are either identical or strict subsets of an idealised dimension (and, by extension, share *exactly* the same naming and structure), then they may be said to be "conformed".  It is expected that the dimension includes at least the values required to support the facts in the database in which it occurs or the Fact Table to which it is paired.
> Example:
>  
> Source S1:
>  
> BIGBIGBIG  (millions of rows)
> bigkey
> ccy
> other_stuff
>  
> CURRENCY   (100s of rows)  let's call it S1_CCY if we need to distinguish
> ccy
> ccy_name
>  
>  
> Source S2:
>  
> BIGGER     (millions of rows)
> biggerkey
> bigkey
> ccy
> more_stuff
>  
> CURRENCY   (100s of rows)  similarly, S2_CCY
> ccy
> ccy_name
>  
>  
> When executing:
>  
> SELECT  B.*
> FROM    BIGBIGBIG    B,
>         CURRENCY     CCY
> WHERE   B.ccy        = CCY.ccy
> AND     CCY.ccy_name LIKE "%DOLLAR%"
>  
> Then it is clearly advantageous to use the copy of CURRENCY in S1 and re-write the query using S1_CCY.  In this situation, federation is eliminated completely.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira