Master issue wrapping multiple tasks with similar topic.
Synopsis: Cube and Dimension representations are logical-to-physical mapping objects. One dimension can have multiple dimension representations and one cube can have multiple cube representations.
Related issues: #118, #24, #264, #372
Problem
Cube mostly a logical concept. It's physical representation might be in a form of a star, snowflake, denormalized table, pre-aggregated rollup. All of the representations are just materializations of the cube.
Similar with a dimension where a dimension can be fully normalized in 3rd normal form or might have some levels grouped in a denormalized tables.
Reasons for such normalization and aggregation might be, performance, easier query-ability, join reduction (applies to both previously mentioned), etc.
Changes
[ ] Replace mappings with representations
[ ] Remove store and store_name from cube, move to the representation
Master issue wrapping multiple tasks with similar topic.
Synopsis: Cube and Dimension representations are logical-to-physical mapping objects. One dimension can have multiple dimension representations and one cube can have multiple cube representations.
Related issues: #118, #24, #264, #372
Problem
Cube mostly a logical concept. It's physical representation might be in a form of a star, snowflake, denormalized table, pre-aggregated rollup. All of the representations are just materializations of the cube.
Similar with a dimension where a dimension can be fully normalized in 3rd normal form or might have some levels grouped in a denormalized tables.
Reasons for such normalization and aggregation might be, performance, easier query-ability, join reduction (applies to both previously mentioned), etc.
Changes
mappingswith representationsstoreandstore_namefrom cube, move to the representationfactfrom cubekeyin cube