Hi OLAP Gurus,

I have to decide whether I should apply OLAP for HR application

Could you please ...help me to decide , below are the requirements,
is this what OLAP for ?

I have a employee database, I need to display employees with these criteria :

- How many employee in one department that meet ALL there conditions :
* have worked > 4 years
* hold Master degree
* age 30-40,
* has passed all required training
* has credit point > 500
* speaking English & German
* (may be some more...)
OR
- How many employee should get a promotion ?
(based on education, training, experience some other variables)

Is this apropriate for OLAP or relational reporting ?

Thanks for your help,
Krist

Your examples seem like typical SQL queries to me.

If you consider a query like
show me the number of employees per department, district, region and
total company as rows on actuals versus budget and variance by %, by
master degree and non-master degree for the corrent month compared to
actuals for last year ...as columns

It's more like a typical OLAP query.

Usually the intervalls (age, degree type etc) are predfined in OLAP
reports,
and the users cannot change them.

RE
Bjørn T


xtanto (AT) hotmail (DOT) com (Krist) wrote in message news:<cb48a3b.0401190631.c77b5f3 (AT) posting (DOT) google.com>...

xtanto (AT) hotmail (DOT) com (Krist) wrote in message news:<cb48a3b.0401190631.c77b5f3 (AT) posting (DOT) google.com>...
Kirst,

You have a list of employee attributes.
You could have a table with each attribute as a column.
Each column could be a dimension in an OLAP database.
However, where are the facts?
Where are the measures that can take on a wide range of values that
can't be pre-defined & therefore are not suitable as dimensions?
Just maybe 'credit point' score is a measure & the rest are
dimensions.
But the query results are not asking for highly aggregated credit
point scores (as this probably makes no sense), the queries are asking
for a list of employees that meet certain criteria.

So I think you are better to use a relational database not OLAP simply
because you are not required to aggregate measures.

Regards,

John

www.misag.com

Hi Bj?rne,

Actually what you mentioned is exactly what I need
i.e : whats the number employee for many conditions like you mentioned.

The question is :
Since what I analyze actually is 'COUNT' of employees,
What value/measures should I put on the fact table ?

Thanks,
Krist


bti (AT) ementor (DOT) no (Bj?rn Tingstadengen) wrote in message news:<f07399d2.0401191501.3d76293f (AT) posting (DOT) google.com>...

Krist,

Why are you so determined to use OLAP for a problem that so obviously
requires a relational solution?

I have already answered your email query twice, and other people have given
similar answers on the news group, but you still seem determined to misuse
OLAP for something where relational technology is more appropriate. This is
NOT a problem that requires OLAP!


"Krist" <xtanto (AT) hotmail (DOT) com> wrote

Hi Krist,

interesting result, isn't it? Two professionals two oppinions. In my
oppinion you can use both technologies each giving you pros and cons.

An OLAP-Application (in contrary to a normalized relational model which is
in fact the opposite) can be built in both technologies since you will have
at least one measure called "Headcount". This measure can be aggregated over
time. I agree to Björns statement that you can easily navigate through a
multidimensional model to analyze data (OLAP analysis). Multidimensional
models are mainly structure driven meaning that you will receive your
numbers when selecting elements in each dimension. I see a challenge for
your data model in dealing with the dates since these dates influence many
of your attributes respectively elements in dimension. A relational data
base offers you date functions to calculate these things, a multidimensional
data base doesn't. So a good strategy could be to calculate your data load
by using a relational data base and importing it into a multidimensional
data base.

Bjørn Tingstadengen stated quite some good hints when to use a
multidimensional data base in reply to another thread (19.01.2004). He
writes:

"Personally I have the following simple rules when to use OLAP:

- Many users quick responsetime required
- Queries against AGGREGATED data primarely
- Flexible reporting (slice and dice....)
- Advanced calclations (financial, time, forecasts etc)
- Read/write like budgets and analysis
- medium to large datavolumes

I think several of these requirements should be met!"

I do fully agree to this.

Kind regards,

Joerg




"Krist" <xtanto (AT) hotmail (DOT) com> schrieb im Newsbeitrag
news:cb48a3b.0401190631.c77b5f3 (AT) posting (DOT) google.com...

"Nigel Pendse" <nigelp.nospam (AT) compuserve (DOT) com> wrote:
his questions, yet Krist wants to embark on a multi-month project to build
and maintain a data warehouse. Nothing like a million dollar DW to answer
how many employees I have.

After thoroughly re-reading your posting I need to adjust my statements:

If you want to *analyze* the data in a way like "how many employees do I
have that meet the criteria" it could be done in an OLAP application. I
would expect you to have an operational application to manage your employees
then. If you need operational-like list-based reports and an application you
can manage your colleques with you are no doubt better off with a
transactional application or a reporting tool for your data base.

However an OLAP application for HR wouldn't cost you millions of dollars nor
would it become a fully blown data warehouse.

J.

Hi All,
Thanks for all response.

I am prototyping a Demo to use MSSQL-AS for the customer.
Now I get the point, It doesn't have to be OLAP, but It can be OLAP.

Again, Thanks,
Krist


"Joerg Narr" <n_o_spa_mjoerg_narr (AT) hotmail (DOT) com> wrote

Krist,

look at your client's requirements. If she needs an operational application
use a normalized transactional data model, if she needs an analytic
application you can think of doing it with relational or multidimensional
OLAP.

Joerg

"Krist" <xtanto (AT) hotmail (DOT) com> schrieb im Newsbeitrag
news:cb48a3b.0401210101.4cff1b00 (AT) posting (DOT) google.com...