How to understand Relationship impact Statement

[barrysaab]

 I am always getting little bit confused by relationship impact statement for ex Sales Staff,Orders it says :Each orders has one and only Sales Staff
         and Each Sales Staff has zero or more Orders

Here relationship is defined by taking into account of whole table ,that is what gets me confused,where as in normal databases for EX: EMP,Dept we focus the relationship solely on Dept.Appreciate if somenone explains this.Sorry for the stupid question,Bummer! Thanks

[MFGF]

Just as in life, relationships are two way things. Here it describes how Staff rows relate to Order rows, and how Order rows relate to Staff rows. The relationship is defining not only which items link the objects, but also the cardinality and optionality.

Regards,

MF.


Snet form my fumblefingers
iPhon 5 usig Tapatalk

[barrysaab]

Thanks,MFGF.I understand what you said,sorry for not being plausible,what i mean to say is in FM we relationship impact describes between Sales Staff and Orders Query Subjects  not between the keys for example let us assume there is order id in sales staff query subject and orders query subject and in normal databases like oracle it would have order id in sales staff has one order id in orders which is cleary between two keys ,where as in FM ,the relationship impact describes relations by query subject. names.Thanks again.

[MFGF]

This is because a relationship can be based on multiple items and/or a coded expression, so defines not just how two items relate to each other, but how the query subjects are related.

Regards,

MF.


Sent from my iPad using Tapatalk

[blom0344]

The relationship impact definition in FM covers both optionality (inner/outer join) and cardinality (1:1  / 1:n) in one statement which - in my humble opinion - is just a tad confusing. 
Optionality is expressed in the join type generated and covered in database terms. 
Cardinality is a modelling concept (primarily to distinguish fact from dimension) . 
Databases do not work with this concept as such, regarding tables as tables.

I notice  lots of people struggling to distinguish between optionality and cardinality

[barrysaab]

Thanks a lot,MFGF and blom.Merry Christmas to all.

[tjohnson3050]

Just to expand a bit on the cardinality - it's main purpose is to define whether or not that query subject will be viewed as a dimension or a fact in the context of that relationship. 

If it is defined as :1 it will be a treated as a dimension, which means that data items defined as a fact (usage property) in the query subject will not necessary be treated as a fact and my not aggregate correctly. 

This usually manifests itself in a report as a single large value being repeated for each detail data item.