unknown cardinality message (DSG0003)

[blom0344]

Hello,

Does anyone have a clue why designer reports the "unknown cardinality message" when checking cardinality between 2 tables. In this case I am joining an itemtable (prim key = item_id) with a stocktable (prim key = item_id,warehouse).
So every item.item_id is joined with zero or more entries from the stocktable.

 

[sagars]

HI,

This is a problem even i faced a couple of times but did not get any help on it. If you get some info then please let me know also.

thanks

 

[blom0344]

Hello Sagars,

It is still an obscure area to me, but i did find some consolation on this site:

http://www.lmgmarketing.com.au/wi/help/ewer50IX.html

which seems to indicate that we are dealing with buggy behaviour we should not worry about. T. Blom
Information analist
Shimano Europe
tbl@shimano-eu.com

 

[promero]

BTW, what are cardinalities for? I know what cardinalities are but, does BusinessObjects use them for something?

I never put cardinalities and I ignore their errors in Designer. Reports work ok.

Much more, in my opinion cardinalities in Designer are bad supported. If two tables (T1, T2) are combined through two fields (A, B), what i must do?
[ul][li]Make two equality joints (T1.A=T2.A, T1.B=T2.B)[/li]
[li]Make a complex joint (SQL edited) with the expression T1.A=T2.A AND T1.B=T2.B[/li][/ul]
Both solutions produce the same SQL code. In the first case, what is supposed to happen if I assign different cardinality to each joint?

 

[blom0344]

Hello Promero,

Cardinalities are just there to give you insight into the relation between two tables like 1:1, 1:n, n:1 , n:m.
Your universe will not be altered by setting cardinalities, but if BO gives the functionality, it should work properly and it doesn't, which is why I started the thread.

If a join over two tables requires two or more fields two equality and one complex join generate the same SQL, indeed.
Cardinality check should be done over the complex join , I imagine, because this is the real relationship between the tables.

Editing a join comes in quite handy if you want to restrict the where clause of a query. Suppose you join a facttable with a lookup table that stores 3 different translations (3 different languages) of a given item from the facttable. Suppose you never want any other translation than the English one. You can then edit the join with something like:

AND TRANSLATE.TYPE = 'ENG'

This will be an effective precaution against getting all data in 3 fold.

P.s. a joinT is something american presidents sometimes seems to indulge in (and admit to, to get a bit of a 'cool' image), we´re talking join's here. T. Blom
Information analist
Shimano Europe
tbl@shimano-eu.com