This is easy in my mind; Firstly you need understand the "derived" dimension; "Derived" dimensions can only be from lookup table, they will be derived from the pk/fk column at runtime; only the FK column will be built into cube; So if you use "derived", you don't need, and have no chance to declare them as hierarchy;
Whether define them as a "derived" or "normal" + "hierarchy", depends on how you balance the pre-aggregation and post-aggregation. 2016-05-10 11:45 GMT+08:00 Mars J <[email protected]>: > It's very confused if I want to define a hierachy dim, I need to define it > be normal or derived and then add it to aggregation group for hierachy > dims. if this hierachy dims I want to define includes 3 columns, it will be > 3 dims if define it in normal dims or 1 dim if define it in derived dims. > So how to handle it ? > > 2016-05-10 10:53 GMT+08:00 Mars J <[email protected]>: > >> Hi, >> There is something confused me . In kylin 1.3 ,the dimension types >> are hierachy/derived/normal and mantory when create a cube in the >> dimensions step. In kylin 1.5.1 there 2 types including normal and derived >> in the dimensions step, and in the advanced setting , aggregation group has >> some aggregating manner of hierachy/mantory/joint. >> >> I test 1.3 including 2 derived dims and 2 hierachy dims(also has 3 >> columns each dims, level1-> level2 -> level3), I said it has 4 dims in the >> traditional BI way, but in kylin ,it's 10 dims. >> In kylin 1.5.1, I can't create hierachy dims directly, but I can >> create it for derived dims or normal dims first, then in the aggregroup , >> make it to hierachy dims. but I don't know how to count it in traditional >> BI way. >> >> We can discuss about the dims, and the different dims definition. >> > > -- Best regards, Shaofeng Shi
