Hi dong, ³Derived² is only for lookup table (and the lookup table need ensure the uniqueness of PK, so with one PK we can exactly find one value for the derived column);
For case 1, Kylin will not support derive from fact table; The problem is, how can we know/ensure 1 region_id only has only 1 region_name mapped if you repeats region_id and region_name in each row of fact table? If there are more than 1 mapping, which one should be taken? If a table column name be changed, the cubes need be updated to use the new name, and a re-build is needed; So you need avoid to change table/column name; (I guess you¹re not mean this, is it?) On 6/17/15, 2:50 PM, "dong wang" <[email protected]> wrote: >usually, we may have 2 common cases: >1, only have a fact table which has already been joined with lookup >tables, >take it as a wide table > >2, we have star schema data model, and when defining the cube, we define >the join with the fact table and lookup tables, > >currently, > >to the 1st case, we cannot create derived dimensions based on the fact >table which can be created only from the lookup tables, for example, we >have fact table: region_id, region_name, province_id, province_name, >city_id, city_name, M1, M2, ...Mn, we want to create a hierarchy >dimension: >region_id->province_id->city_id, and a derived dimenison: (region_name, >province_name, city_name) as well, if we can achieve it, there will be no >complicated joins at all, and also, the join will take much time in the >first step when building the cube~ thus, will we support such demension >design? > >to the 2nd case, even though we make the join, however, if the column >names >are changed for some reasons, we will have to build the whole cube again >instead of only update the dimension data?
