+ Reply to Thread
Results 1 to 8 of 8

employee dimension structure question...

  1. employee dimension structure question...

    Hi,

    I'm looking for samples models for an HR model and specially the employee
    dimension table.

    What is better a slow changing dimension (with full history in the
    dimension)?
    or separate dimensions? I mean age, "current" organisation (or organization
    unit), position etc... in separate tables.

    Solution 1: maybe difficult to maintain
    Solution 2: a lot of small tables

    I'll create OLAP cubes for ad-hoc analysis & reports based on SQL
    statements.
    I know that I'll have dynamic distinct count formulas to setup in my cubes
    (not the dcount aggregation one)

    what are your recommendations?
    any samples?

    thanks.

    Jerome.



  2. Re: employee dimension structure question...

    Basically Employee dimension is a parent child dimension, which is
    always a rapidly changing
    You checking on the property "Changing" and see also BOL on the same.
    They do fall under rapidly changing dimension rather than Slowly
    changing dimension

    Regards,
    Prasanna


  3. Re: employee dimension structure question...

    I think I'm not clear.

    I'm looking for a complete sample with complete employee dimension based on
    hundrers of attributes, geographical information, organization information
    etc...

    Its not a simple changing question, its a complete design question.

    For the moment I focus on a hybrid solution, I mean 2 tables 1 for the
    historical information (type 2 dimension) and 1 for the "current"
    information.

    "pras" wrote in message
    news:1121405740.245158.172240@g43g2000cwa.googlegroups.com...
    > Basically Employee dimension is a parent child dimension, which is
    > always a rapidly changing
    > You checking on the property "Changing" and see also BOL on the same.
    > They do fall under rapidly changing dimension rather than Slowly
    > changing dimension
    >
    > Regards,
    > Prasanna
    >




  4. Re: employee dimension structure question...

    I recommend you Kimball's "DataWarehouse Toolkit".. Chapter 8.. Excelent
    Human Resources Management model.

    Regards
    Rodrigo

    <

    "Jéjé" wrote:

    > I think I'm not clear.
    >
    > I'm looking for a complete sample with complete employee dimension based on
    > hundrers of attributes, geographical information, organization information
    > etc...
    >
    > Its not a simple changing question, its a complete design question.
    >
    > For the moment I focus on a hybrid solution, I mean 2 tables 1 for the
    > historical information (type 2 dimension) and 1 for the "current"
    > information.
    >
    > "pras" wrote in message
    > news:1121405740.245158.172240@g43g2000cwa.googlegroups.com...
    > > Basically Employee dimension is a parent child dimension, which is
    > > always a rapidly changing
    > > You checking on the property "Changing" and see also BOL on the same.
    > > They do fall under rapidly changing dimension rather than Slowly
    > > changing dimension
    > >
    > > Regards,
    > > Prasanna
    > >

    >
    >
    >


  5. Re: employee dimension structure question...

    yes, its a good starting point.
    but there is no list of attributes and no sample about how to organize this
    dimension for a hierarchical view (I mean OLAP dimension)

    I know I have to work with my users, but I want to be prepared with samples
    and recommendations (best practices)

    "Rodrigo" wrote in message
    news:7261A1BB-E723-45FD-9F47-EF02DE63BE07@microsoft.com...
    >I recommend you Kimball's "DataWarehouse Toolkit".. Chapter 8.. Excelent
    > Human Resources Management model.
    >
    > Regards
    > Rodrigo
    >
    > <
    >
    > "Jj" wrote:
    >
    >> I think I'm not clear.
    >>
    >> I'm looking for a complete sample with complete employee dimension based
    >> on
    >> hundrers of attributes, geographical information, organization
    >> information
    >> etc...
    >>
    >> Its not a simple changing question, its a complete design question.
    >>
    >> For the moment I focus on a hybrid solution, I mean 2 tables 1 for the
    >> historical information (type 2 dimension) and 1 for the "current"
    >> information.
    >>
    >> "pras" wrote in message
    >> news:1121405740.245158.172240@g43g2000cwa.googlegroups.com...
    >> > Basically Employee dimension is a parent child dimension, which is
    >> > always a rapidly changing
    >> > You checking on the property "Changing" and see also BOL on the same.
    >> > They do fall under rapidly changing dimension rather than Slowly
    >> > changing dimension
    >> >
    >> > Regards,
    >> > Prasanna
    >> >

    >>
    >>
    >>




  6. Re: employee dimension structure question...

    Hi,

    Beside having a complete example, if you are able to define history
    duration, number of attributes for which you require history and ofcourse
    number of total attributes in dimension then you can really design your
    mart.

    If you are able to set a particular condition for history then you can
    decide on having copy of each required attributes as many time as history is
    required or can have snowflake model and further normalize the employee
    dimension. Then there are few techniques to improve the query performance,
    like, by adding a flag attribute to show the latest image of record.

    Frankly speaking, from your email i am under the impression that you would
    be keeping almost all the information in history; this does not look real.

    Regards,
    ..Mumtaz


    "Jj" wrote in message
    news:O4JP5CXiFHA.1048@tk2msftngp13.phx.gbl...
    > yes, its a good starting point.
    > but there is no list of attributes and no sample about how to organize

    this
    > dimension for a hierarchical view (I mean OLAP dimension)
    >
    > I know I have to work with my users, but I want to be prepared with

    samples
    > and recommendations (best practices)
    >
    > "Rodrigo" wrote in message
    > news:7261A1BB-E723-45FD-9F47-EF02DE63BE07@microsoft.com...
    > >I recommend you Kimball's "DataWarehouse Toolkit".. Chapter 8.. Excelent
    > > Human Resources Management model.
    > >
    > > Regards
    > > Rodrigo
    > >
    > > <
    > >
    > > "Jj" wrote:
    > >
    > >> I think I'm not clear.
    > >>
    > >> I'm looking for a complete sample with complete employee dimension

    based
    > >> on
    > >> hundrers of attributes, geographical information, organization
    > >> information
    > >> etc...
    > >>
    > >> Its not a simple changing question, its a complete design question.
    > >>
    > >> For the moment I focus on a hybrid solution, I mean 2 tables 1 for the
    > >> historical information (type 2 dimension) and 1 for the "current"
    > >> information.
    > >>
    > >> "pras" wrote in message
    > >> news:1121405740.245158.172240@g43g2000cwa.googlegroups.com...
    > >> > Basically Employee dimension is a parent child dimension, which is
    > >> > always a rapidly changing
    > >> > You checking on the property "Changing" and see also BOL on the same.
    > >> > They do fall under rapidly changing dimension rather than Slowly
    > >> > changing dimension
    > >> >
    > >> > Regards,
    > >> > Prasanna
    > >> >
    > >>
    > >>
    > >>

    >
    >




  7. Re: employee dimension structure question...

    Hi,

    first point ... oohhh no ! I don't want to keep all information in history.
    Only required information.

    But I have to create a prototype for this HR data warehouse.
    I have some idea about some facts, but I want to demonstrate the importance
    of the employee dimension. Also I want to have your input about the overall
    design of this DW.
    So sample list of attributes around the employee is welcome, and sample
    hierarchy to render this dimensions in a cube is welcome too.

    My actual facts: Activities (who do what when), Contracts (head count,
    duration...), Training (achivement, resulting promotions...), Salaries (no
    comment), Expenses (no comments), absences


    "Mumtaz Zaheer" wrote in message
    news:%23Yi6UPRjFHA.1372@TK2MSFTNGP10.phx.gbl...
    > Hi,
    >
    > Beside having a complete example, if you are able to define history
    > duration, number of attributes for which you require history and ofcourse
    > number of total attributes in dimension then you can really design your
    > mart.
    >
    > If you are able to set a particular condition for history then you can
    > decide on having copy of each required attributes as many time as history
    > is
    > required or can have snowflake model and further normalize the employee
    > dimension. Then there are few techniques to improve the query performance,
    > like, by adding a flag attribute to show the latest image of record.
    >
    > Frankly speaking, from your email i am under the impression that you would
    > be keeping almost all the information in history; this does not look real.
    >
    > Regards,
    > .Mumtaz
    >
    >
    > "Jj" wrote in message
    > news:O4JP5CXiFHA.1048@tk2msftngp13.phx.gbl...
    >> yes, its a good starting point.
    >> but there is no list of attributes and no sample about how to organize

    > this
    >> dimension for a hierarchical view (I mean OLAP dimension)
    >>
    >> I know I have to work with my users, but I want to be prepared with

    > samples
    >> and recommendations (best practices)
    >>
    >> "Rodrigo" wrote in message
    >> news:7261A1BB-E723-45FD-9F47-EF02DE63BE07@microsoft.com...
    >> >I recommend you Kimball's "DataWarehouse Toolkit".. Chapter 8..
    >> >Excelent
    >> > Human Resources Management model.
    >> >
    >> > Regards
    >> > Rodrigo
    >> >
    >> > <
    >> >
    >> > "Jj" wrote:
    >> >
    >> >> I think I'm not clear.
    >> >>
    >> >> I'm looking for a complete sample with complete employee dimension

    > based
    >> >> on
    >> >> hundrers of attributes, geographical information, organization
    >> >> information
    >> >> etc...
    >> >>
    >> >> Its not a simple changing question, its a complete design question.
    >> >>
    >> >> For the moment I focus on a hybrid solution, I mean 2 tables 1 for the
    >> >> historical information (type 2 dimension) and 1 for the "current"
    >> >> information.
    >> >>
    >> >> "pras" wrote in message
    >> >> news:1121405740.245158.172240@g43g2000cwa.googlegroups.com...
    >> >> > Basically Employee dimension is a parent child dimension, which is
    >> >> > always a rapidly changing
    >> >> > You checking on the property "Changing" and see also BOL on the
    >> >> > same.
    >> >> > They do fall under rapidly changing dimension rather than Slowly
    >> >> > changing dimension
    >> >> >
    >> >> > Regards,
    >> >> > Prasanna
    >> >> >
    >> >>
    >> >>
    >> >>

    >>
    >>

    >
    >




  8. Re: employee dimension structure question...

    Hi,

    http://www.dbmsmag.com/9802d05.html

    If you have not gone thru this before, try applying to your scenario.

    I guess, you would require more than just one Employee Dimension.

    So far, I believe in keeping history in DW not Mart :)

    Regards

    "Jj" wrote in message
    news:u2fbzYSjFHA.2904@tk2msftngp13.phx.gbl...
    > Hi,
    >
    > first point ... oohhh no ! I don't want to keep all information in

    history.
    > Only required information.
    >
    > But I have to create a prototype for this HR data warehouse.
    > I have some idea about some facts, but I want to demonstrate the

    importance
    > of the employee dimension. Also I want to have your input about the

    overall
    > design of this DW.
    > So sample list of attributes around the employee is welcome, and sample
    > hierarchy to render this dimensions in a cube is welcome too.
    >
    > My actual facts: Activities (who do what when), Contracts (head count,
    > duration...), Training (achivement, resulting promotions...), Salaries (no
    > comment), Expenses (no comments), absences
    >
    >
    > "Mumtaz Zaheer" wrote in message
    > news:%23Yi6UPRjFHA.1372@TK2MSFTNGP10.phx.gbl...
    > > Hi,
    > >
    > > Beside having a complete example, if you are able to define history
    > > duration, number of attributes for which you require history and

    ofcourse
    > > number of total attributes in dimension then you can really design your
    > > mart.
    > >
    > > If you are able to set a particular condition for history then you can
    > > decide on having copy of each required attributes as many time as

    history
    > > is
    > > required or can have snowflake model and further normalize the employee
    > > dimension. Then there are few techniques to improve the query

    performance,
    > > like, by adding a flag attribute to show the latest image of record.
    > >
    > > Frankly speaking, from your email i am under the impression that you

    would
    > > be keeping almost all the information in history; this does not look

    real.
    > >
    > > Regards,
    > > .Mumtaz
    > >
    > >
    > > "Jj" wrote in message
    > > news:O4JP5CXiFHA.1048@tk2msftngp13.phx.gbl...
    > >> yes, its a good starting point.
    > >> but there is no list of attributes and no sample about how to organize

    > > this
    > >> dimension for a hierarchical view (I mean OLAP dimension)
    > >>
    > >> I know I have to work with my users, but I want to be prepared with

    > > samples
    > >> and recommendations (best practices)
    > >>
    > >> "Rodrigo" wrote in message
    > >> news:7261A1BB-E723-45FD-9F47-EF02DE63BE07@microsoft.com...
    > >> >I recommend you Kimball's "DataWarehouse Toolkit".. Chapter 8..
    > >> >Excelent
    > >> > Human Resources Management model.
    > >> >
    > >> > Regards
    > >> > Rodrigo
    > >> >
    > >> > <
    > >> >
    > >> > "Jj" wrote:
    > >> >
    > >> >> I think I'm not clear.
    > >> >>
    > >> >> I'm looking for a complete sample with complete employee dimension

    > > based
    > >> >> on
    > >> >> hundrers of attributes, geographical information, organization
    > >> >> information
    > >> >> etc...
    > >> >>
    > >> >> Its not a simple changing question, its a complete design question.
    > >> >>
    > >> >> For the moment I focus on a hybrid solution, I mean 2 tables 1 for

    the
    > >> >> historical information (type 2 dimension) and 1 for the "current"
    > >> >> information.
    > >> >>
    > >> >> "pras" wrote in message
    > >> >> news:1121405740.245158.172240@g43g2000cwa.googlegroups.com...
    > >> >> > Basically Employee dimension is a parent child dimension, which is
    > >> >> > always a rapidly changing
    > >> >> > You checking on the property "Changing" and see also BOL on the
    > >> >> > same.
    > >> >> > They do fall under rapidly changing dimension rather than Slowly
    > >> >> > changing dimension
    > >> >> >
    > >> >> > Regards,
    > >> >> > Prasanna
    > >> >> >
    > >> >>
    > >> >>
    > >> >>
    > >>
    > >>

    > >
    > >

    >
    >




+ Reply to Thread