Luke, Thanks for the quick reply. The hierarchy dimension is hopefully just what we need then.
However, testing this out gives me errors in the cube build step. If I include 2 columns in the hierarchy dimension (clicking "+new hierarchy" twice), the build job is scheduled, but fails on the "Build Dimension Dictionary" step. If I include a singular hierarchy column for said dimension, scheduling the cube build fails with the error: "Can't find column <DB NAME>_<TABLE NAME>_<COLUMN NAME>". It seems there are underscores here in the place of dots; shouldn't it be "<DB NAME>.<TABLE NAME>.<COLUMN NAME>"? For the build job that schedules but fails, I cannot access the logs via the UI, the "loading" spinner just spins indefinitely. Would these be helpful to look at, and if so where would they reside? On Wed, Sep 16, 2015 at 11:51 AM, Luke Han <[email protected]> wrote: > If they are one-to-many relationship, it will be easy to roll up to parent > level, the hierarchy dimension is designed for that. > > > Best Regards! > --------------------- > > Luke Han > > On Wed, Sep 16, 2015 at 10:15 PM, Patrick McAnneny < > [email protected]> wrote: > > > If I had a singular large fact table comprised of a row for every event I > > am tracking, and there are rows that have parent or child events (within > > this same table), could kylin handle these relationships accordingly? Can > > the cube be configured to roll up measures based on parent rows? > > > > Thanks > > >
