Relationships - Framework Manager

[dssd]

Is it ok to only put relationships in Business view. I have a set where there are no relationships in data source views?

[Lynn]

Take a look at chapter 8 in the FM user guide. There is a section called "Where Should You Create Relationships and Determinants?"

The answer (of course) is "It Depends..."

Generally speaking, creating the relationships in the data source layer will result in minimized SQL while relationships in the business layer will give you SQL generated as a view. The difference between these two situations is also explained in the user guide.

[dssd]

Thanks. Also had one more question. My FM has a determinent, but there is only one level. A determinent defined for a SystemID.  Does it serve any purpose? I thought it makes sense to have multi llevel like year, month, date.

[Lynn]

There was a rather in depth discussion on that topic here:

http://www.cognoise.com/community/index.php/topic,11557.0.html

[dssd]

One more query. I have facts which are linked to many different query subjects...In some relationships, fact is 1..1  to 0..n and in some cases 1..n to 1..1 ...so it is ambiguous...I believe this causes ambiguous results and performance issues. Is that correct

[blom0344]

No , a fact may have a non-mandatory FK demanding an outer join to prevent data-loss. If the FK is mandatory a straight (inner) join can be modelled. So,you may need both scenarios.
Outer joins can degrade performance, but may be unavoidable

[dssd]

Bloom, what i meant was on occasions the fact has a n on its side and on other occasions a 1or 0 on its side..........So if A is related to B, at times its n..1 and on other occasions its the other way round 1..n

Is that a bad practice to keep as it is?  What do we do in such occasions