to clarify in my use case the data can be organized to either have a couple fact tables or a large single one. Queries are open ended at this point. queries may cross facts or may not.
On Wed, Mar 8, 2017 at 5:13 PM, Sonny Heer <[email protected]> wrote: > Let me put it anther way. assume a SALES table and a PRODUCT table. This > is not highly normalized in the grand scheme of things, but somewhat. The > question is what benefit is there to denormalize this further into a single > table for kylin. i read something about hierarchical dimensions. So from > Kylin perspective which is better. have one-to-many in a single table or > some normalized form? > > On Wed, Mar 8, 2017 at 4:24 PM, Billy Liu <[email protected]> wrote: > >> please check star schema first： https://en.wikipedia.org/wiki/Star_schema >> >> 2017-03-08 12:48 GMT-08:00 Sonny Heer <[email protected]>: >> >>> Hi I'm somewhat new to Kylin. we have a relational db schema imported >>> into hive as is at the moment. The schema is highly normalized with lots >>> of tables. I can see this database having multiple fact tables or a >>> handful of fact tables. >>> >>> In Kylin I see when creating a model (star) you have the option to pick >>> a single fact table...meaning there is a single cube per fact table. >>> Please provide pros/cons on running transformations to denormalize the >>> tables into a single table vs keeping lots of tables with many fact/lookup >>> tables. >>> >>> In short: >>> should we do any transformations in Hive before presenting the tables to >>> kylin for cubing?... >>> >>> Thanks >>> >> >> > > > -- > > > Pushpinder S. Heer > Senior Software Engineer > m: 360-434-4354 <(360)%20434-4354> h: 509-884-2574 <(509)%20884-2574> > -- Pushpinder S. Heer Senior Software Engineer m: 360-434-4354 h: 509-884-2574
