1) If you notice that query is joining on rsum then we know that its not correct
2) For a stitched query to work correctly both the facts should have one column in common , without that the stitched query that is formed will be wrongly joined
3) if you notice a query joined on RSUM you can put a filter and make one of the table that cognos is considering fact a non fact, this has to be so because if the table was a fact adn joined by confirmed dimension it will have one column that is common
4) combine the table which is acting as a fact into a single one .The way to do is i guess use a single folder put both the talbe in
the folder delete any joins to the tables and put a single join condition in the folder this make cognos treat this table as a
single table and join is always included ??
Not quite sure about this need to try --- refer page 329 cognos 10 user guide
order header and order method are put in a folder in busineess layer that is a relationship is created between their model query subjecsts .This will cause it to function as a view . so when you pick anything from any one of the tables the join between both the tables is taken into consideration and they function as a single table so they wont act as a fact but a single table .
If you create a model query subject and put the both teh tables into this query subject or you create a folder what is the differnece
in both these approaches and how the query formation will be different.
Folder creation has no effect on the query generation however if you create a join on model query subject it will override teh minimised sql property .
If you create model query subject which is a combination of differnet data source query subjects like in case of product line product type etc.This will still preserve your minimised sql property .Table will be joined only when required.
How to resolve fact less query issue ???? -------- by creating a star schema grouping ? what is other way of solving this ??
How to make a snowflaked schema into star schema???
What are stitched queries
Are they formed when two facts are joined on confirmed dimension .
If instead of two confirmed dimension and two facts in a framework we change teh relationship to 1 to 1 from 1 to n it will give rise to a loop . and how do we resolve the loop .How cognos automatically solves the loop .( Cognos will drop the last join that formed teh loop )
what woule happen if there was a loop in any sql statement ??? depends on data if the data keeps changing then the sql will run for long time as a = b =c =a
depending on c again a will change that will cause b to change and so on .
The standard example that we see that is two facts and two dimension for stiched query will fail in case of factless query so we need to go for star schema grouping .
How cogons ensures that the joins are made on lowest level of granularity .. consider the example of one fact on month grain and othe on day .How will the joine handled to take care of the granularity ?? (Note that result are always executed on lowest common level of granularity in this case that is month)
If a query subject participates in both 1 and n relationship its called ambiquosly defined
One case when we can see that a query subject is ambiquosly defined when it reprents a part of hierarchy.so in such case examine how the query is formed and what does cognos treats as a fact and what does it represents as a dimension.
------------How does the query join change when you join a dimensiotn to a fact .Does it represetn a left outer join or will it be a inner join
.
How does a the query changes on addition of a non confimred dimension to multi fact multi grain query
what are governor setting and how does it help you to improve model performance??
2) For a stitched query to work correctly both the facts should have one column in common , without that the stitched query that is formed will be wrongly joined
3) if you notice a query joined on RSUM you can put a filter and make one of the table that cognos is considering fact a non fact, this has to be so because if the table was a fact adn joined by confirmed dimension it will have one column that is common
4) combine the table which is acting as a fact into a single one .The way to do is i guess use a single folder put both the talbe in
the folder delete any joins to the tables and put a single join condition in the folder this make cognos treat this table as a
single table and join is always included ??
Not quite sure about this need to try --- refer page 329 cognos 10 user guide
order header and order method are put in a folder in busineess layer that is a relationship is created between their model query subjecsts .This will cause it to function as a view . so when you pick anything from any one of the tables the join between both the tables is taken into consideration and they function as a single table so they wont act as a fact but a single table .
If you create a model query subject and put the both teh tables into this query subject or you create a folder what is the differnece
in both these approaches and how the query formation will be different.
Folder creation has no effect on the query generation however if you create a join on model query subject it will override teh minimised sql property .
If you create model query subject which is a combination of differnet data source query subjects like in case of product line product type etc.This will still preserve your minimised sql property .Table will be joined only when required.
How to resolve fact less query issue ???? -------- by creating a star schema grouping ? what is other way of solving this ??
How to make a snowflaked schema into star schema???
What are stitched queries
Are they formed when two facts are joined on confirmed dimension .
If instead of two confirmed dimension and two facts in a framework we change teh relationship to 1 to 1 from 1 to n it will give rise to a loop . and how do we resolve the loop .How cognos automatically solves the loop .( Cognos will drop the last join that formed teh loop )
what woule happen if there was a loop in any sql statement ??? depends on data if the data keeps changing then the sql will run for long time as a = b =c =a
depending on c again a will change that will cause b to change and so on .
The standard example that we see that is two facts and two dimension for stiched query will fail in case of factless query so we need to go for star schema grouping .
How cogons ensures that the joins are made on lowest level of granularity .. consider the example of one fact on month grain and othe on day .How will the joine handled to take care of the granularity ?? (Note that result are always executed on lowest common level of granularity in this case that is month)
If a query subject participates in both 1 and n relationship its called ambiquosly defined
One case when we can see that a query subject is ambiquosly defined when it reprents a part of hierarchy.so in such case examine how the query is formed and what does cognos treats as a fact and what does it represents as a dimension.
------------How does the query join change when you join a dimensiotn to a fact .Does it represetn a left outer join or will it be a inner join
.
How does a the query changes on addition of a non confimred dimension to multi fact multi grain query
what are governor setting and how does it help you to improve model performance??
No comments:
Post a Comment