Information Design Tool has two methods to detect cardinality:
Based on row count. Information Design Tool creates three count distinct scripts in order to count the number of rows in the firtst table, the second table and one script for counting rows from both tables and adds the join, whose cardinality has to be detected in it.If the number of rows in the smaller table (1) equals the number of rows of the third script, it assigns a one-to-many cardinality between table (1) and table (2). This method is slow with large tables, especially when both tables are large and it is sometimes incorrect if the tables are small.
Based on keys. If a joins links a foreign key column with a primary key column then IDT assigns a Many-to-one cardinality between the foreign key column table and the primary key column table. This method is in my opionion always correct as long as the assignment of keys is correct and it is very fast. Because keys can be maintained on database level and IDT is able to read that information from the database this method is the better one. IDT chooses this method as long as key information is available. Otherwise it uses the row count method.
Check in the backend db, table structure/records,how the rows are coming,whether some column values are repeating or not repeating, and most importantly how the table is related to the other table and how the report requirements are/going to be.
The basic thumb rule is you should know the business logic of the functional domain you are working,and then know about what is this table about and what each fields meant to be,only a business analyst/functional domain expert could guide you on this.
That is the case when you can checking cardinality between two large tables where volume is high.in that case auto detect cardinality will take time to show the relationship.
check this link on more cardinality or check universe designer guide.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.