If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

how to set the cardinality dimension to dimension

Started by inu, 01 May 2014 09:58:30 AM

Previous topic - Next topic

inu

Hi
I have sales project, where i have given all the joins, except one that is country dimension table. i cant join it to sales fact table, becoz country_id is not available in sales fact table but available in customer dimension table. so what i m doing. i m joining customer dimension to country dimension. when i set the cardinality, i m confused whether it should be one<-->one relationship or one<-->many. is it possible to give one to many relationship in dimension to dimension table.
i just want to clarify myself, how to handle this situation.

Tell me what should i do.

Regards
Inam

MFGF

Quote from: inamulhaque on 01 May 2014 09:58:30 AM
Hi
I have sales project, where i have given all the joins, except one that is country dimension table. i cant join it to sales fact table, becoz country_id is not available in sales fact table but available in customer dimension table. so what i m doing. i m joining customer dimension to country dimension. when i set the cardinality, i m confused whether it should be one<-->one relationship or one<-->many. is it possible to give one to many relationship in dimension to dimension table.
i just want to clarify myself, how to handle this situation.

Tell me what should i do.

Regards
Inam

Hi,

In this instance it sounds like you have a snowflake schema, where Country is a logical hierarchical level sitting above Customer. It's fine to join Country to Customer 1..1 <---> 1..n because you expect to see this within a snowflake dimension. best practice advocates modelling as a star or a snowflake, so you're fine doing this.

In reality you will have a single logical dimension containing info from both Country and Customer tables. If you want to you could merge these into a single model query subject, but here I don't see a need.

Cheers!

MF.

Meep!