Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Cognos Sql
- Thread starter UcfMike
- Start date
Probably indifferent. The Cognos server uses an UDA (universal dataaccess) compiler to rewrite the statement to native SQL that is send to the database.
When you check the native SQL you will notice that this is a proper SQL in any case
Ties Blom
When you check the native SQL you will notice that this is a proper SQL in any case
Ties Blom
- Thread starter
- #3
Seems were are struggling with the same kind of questions.
We're currently trying to convert BO universes to C8 frameworks (that cover 100% relational models)
Framework best practices would suggest:
1. Objects that are part of a primary/foreign key, or those that are otherwise involved in joins , as well as dates should be set to identifier with aggregate behavior to count.
2. Objects that are numeric and not a code or key should be identified as facts. Aggregate set as sum.
3. All other objects are attributes.
To our surprise version 8.2 fails to correctly indicate the usage-type from the reporting modules. It also seems to skip on indicating query subjects that contain facts.
Weird.
Ties Blom
We're currently trying to convert BO universes to C8 frameworks (that cover 100% relational models)
Framework best practices would suggest:
1. Objects that are part of a primary/foreign key, or those that are otherwise involved in joins , as well as dates should be set to identifier with aggregate behavior to count.
2. Objects that are numeric and not a code or key should be identified as facts. Aggregate set as sum.
3. All other objects are attributes.
To our surprise version 8.2 fails to correctly indicate the usage-type from the reporting modules. It also seems to skip on indicating query subjects that contain facts.
Weird.
Ties Blom
- Thread starter
- #5
Since I haven't received any formal training, and the Cognos documentation isn't always comprehensive, I initially set all of my usage properties to unknown and left the counts as unsupported. I'm changing that now off the advice of a Cognos developer with the parent company. Interestingly, she sent me an email about the same time you posted your last response. I wasn't setting my dates as identifiers, but I will now.
I've been having fits the last two weeks with a new model I'm building because I kept getting stitch queries between query subjects. The problem was the determinants in the query subjects. I've since removed all determinants from all query subjects, and that seems to have fixed the problem.
I wish I could import tables into Framework Manager, and it wouldn't set any attributes or properties. It seems to do a poor job of guessing.
I've been having fits the last two weeks with a new model I'm building because I kept getting stitch queries between query subjects. The problem was the determinants in the query subjects. I've since removed all determinants from all query subjects, and that seems to have fixed the problem.
I wish I could import tables into Framework Manager, and it wouldn't set any attributes or properties. It seems to do a poor job of guessing.
I have yet to find a definitive paper on the use of determinants. Just a lot of half-answers and guessing.
Officially determinants should provide for correct results when multi-fact, multi-grain queries are the issue.
I can follow that train of thought. But where does that leave us with truly relational schema's?
The problem is that the more relational the model, the more problems we seem to encounter.
My hope is to persuade management to spend some money on a real guru and not stick with following 'official' courses where some teacher spends it's time on the a very simple and suitable datamodel. Real life is a little rougher!
In my old Business Objects days we could apply a context to each facttable (with its dimensional tables) and BO would come up with split queries that were synchronized at the client side. Good clean solution.
This webbusiness thing makes it all much harder..
Ties Blom
Officially determinants should provide for correct results when multi-fact, multi-grain queries are the issue.
I can follow that train of thought. But where does that leave us with truly relational schema's?
The problem is that the more relational the model, the more problems we seem to encounter.
My hope is to persuade management to spend some money on a real guru and not stick with following 'official' courses where some teacher spends it's time on the a very simple and suitable datamodel. Real life is a little rougher!
In my old Business Objects days we could apply a context to each facttable (with its dimensional tables) and BO would come up with split queries that were synchronized at the client side. Good clean solution.
This webbusiness thing makes it all much harder..
Ties Blom
- Thread starter
- #7
Sounds like we are facing similar type problems. I'm still working against a relational database without a data warehouse, so all of my incoming information is relational without any ETL processes to make it report writing friendly. It can be a little frustrating. I'm trying to convince my boss to send me to the metadata modeling class.
From talking with people, you are probably more of an expert than 98% of the people out there.
From talking with people, you are probably more of an expert than 98% of the people out there.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question